|
Why would I ever need to "fetch" the tables? I'm doing an Insert/Delete/Update.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: Why would I ever need to "fetch" the tables? I'm doing an Insert/Delete/Update.
Most things that are written are read at some point. Let me rephrase then, what alternative would there be compared to passing the userId when you insert/delete/update?
How about Functions That Return User Names and User IDs[^]? 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Your question is phrased in such a way that it is confusing.
Summary of the actual problem.
1. You have a number of tables which you want to update with information specific to the user that initiated the action.
2. You want to know how to get the user information, automatically, to the point to where it is used.
First problems with this architecture.
1. You said "all". Generally a bad idea. Often tables represent structure that has nothing to do with users and keeping data specific to the user every where is pointless.
2. It is better to track what a user did in the business sense and not in the data sense. This leads to several requirements that you often want to know what general action initiated the action, you want to keep the entire history (more than one user) and you need to deal with what happens when a user is deleted from the system.
3. Automated processes can be required to update a system. They have not user.
4. Some systems allow for one user to act on the behalf of another user. Single data collection points do not allow for that action to be captured.
Solution to your specific problem is as follows.
1. A user action is either initiated as a request (thread level) or a message (not thread level.)
2. As a request you can use the class ThreadLocal to store the user and then many layers later you retrieve the user from the ThreadLocal for use in your DAL.
3. A message has no way to transport that information except via a specific attribute. But the message should have originated as a request (real people must always start with real UI actions) so one uses 2 at the point where the message is created to add the user to the message. Then end that processes the message (again in a thread) extracts the user and puts it into the ThreadLocal that is processing now.
I suggest that you insure at and request origination point that you should, for all exit points, including exceptions, clear the user.
I suggest that you test the usage of the user at all usage points to insure that it does in fact exist, before attempting to use it. That insures no null pointers.
I suggest creating a user proxy object, do NOT use the original DAL user object, to contain the information about the user. That proxy object must be exposed to ALL layers whereas the DAL user object should not be.
|
|
|
|
|
Blockchain!
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
if u solved can u give the code... 
|
|
|
|
|
I have solved it but I can't give it to you as you aren't a level 8 wizard.
This space for rent
|
|
|
|
|
What about a level 9 cleric?
Natch it is never usable by a barbarian regardless of level.
|
|
|
|
|
I have an old Silverlight application that I would like to convert for demonstration purposes. Converting to WPF is relatively trivial.
Does the hive mind know if it is possible to:
Deploy SQL Server to Azure - Yes
Deploy a WCF to Azure
Use clickonce deployment via Azure
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
I feel like a ditz, I found both of them after I posted.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
The back end is C# / MVC / Knockout
I've been trying to figure this out for a while with no luck. I can get it to partially work but the session is never passed back to the end user.
What I'm trying to figure out is how to add a single signon (non SAML/oAuth; that's already working) to authenticate a user to a remote site using a username / password combination. Most sites are HTML so from the server I can issue a login and it works. If I try to do this through the browser I get cross-site scripting errors (which I would expect). I know other people are doing this successfully. I need to do this device / browser independent. Outside of writing either a plugin for each browser, how is this accomplished?
|
|
|
|
|
I have these options =
A. Store more data into one single JSON document
Or
B. Distribute them as multiple documents
Storing data in one single doc, gives a neat solution, but I'm not sure how big is too big for a JSON document. What if it runs to 40-50 MB? Parsing docs of this size feels insane?
UPDATED:
This document works like an accumulator. For example, lets assume a requirement like this :
I need to store all the users taking part in discussions in CodeProject.
So, I need to capture the User ID & have a counter against each of them.
{User:1332,
PostCount:23, (incremented every time he posts a reply)
},
{User:1124,
PostCount:56,
},
{User:2323
PostCount:34
}
The document keeps growing as and when new users start posting in CP.
The document gets updated for the count, when old users make another post.
The document is read when the user metrics are needed to be shown on reports.
Now I have the option to maintain it- Yearly, Monthly or weekly OR just Keep it as a single document. Where all the users activities would be recorded in a single doc.
If you are dividing the document as Yearly, Monthly,weekly etc, The document size would be reasonable- Somewhere around <4-5MB (Monthly), but the no. of document would be more in the collection. You'll have to run an aggregate function to collect all the data & calculate the Count that's spread across documents for every user and produce the metrics. As I just said, Here the individual documents size would be reasonable as it can't go on increasing. It just bound by the start & end date.
And Single document means, Keeping everything in single file and keep updating it.
For calcs, Load the whole data in memory, run the aggregate function to parse through the document and produce the metrics.
(Single Document sounds like a Big-Fat approach. I think I'd rather keep them as monthly chunks and make it handy to handle the documents.)
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
modified 1-Dec-17 5:28am.
|
|
|
|
|
At that size it is no longer an exchange-format, but used as a data-store. In that case SQLite would probably be a better option.
Once wrote an application that used XML as a datastore; every edit means rewriting the entire file.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yep its a data-dump-store. Though a single document looks neat on the design, I guess performance wise its a bad thing. Mainly for the reason you mentioned, it has to load whole lot of data into memory everytime it has to update or read something. On the other hand, if I'm distributing it into multiple documents, it will need proper indexing/partitionin/sharding things done right.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
|
|
|
|
|
Vunic wrote: On the other hand, if I'm distributing it into multiple documents, it will need proper indexing/partitionin/sharding things done right.
JSON, XML and CSV are great formats for exporting data; but they do not work well as datastores where frequent updates are expected. If your data contains images, they'll probably be stored in Base64, making the file even larger. If there is no updates expected to the data, and it is merely a static export - then one of the text-based exports is preferred. Reading is fast enough for text, but updating takes a severe and noticable penalty.
Vunic wrote: Though a single document looks neat on the design
Also a lot easier when making backups and sending stuff. I prefer to put all data in a single file; with a file-based database like SQLite, SQLCe and MSAccess you can easily even store binary data. Another nicety is that you can link to these databases from SQL Server and interact with them as if they were local SQL Server databases.
If the data is not related at all, then I'd recommend zipping your various documents, so it remains "one file" in the eye of the end-user. Since you initially chose JSON, I'd be expecting data that is somehow related.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I have updated the OP[^] Please check the sample scenario.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
|
|
|
|
|
You can't just look at a "number" and say it is "too big" (or small) without benchmarking.
Most internet traffic is automatically "zipped" (gzipped) by default; and will on average compress to 10% of its original (text) size. That addresses bandwidth.
Where else is is it "too big"?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: You can't just look at a "number" and say it is "too big" (or small) without benchmarking.
If you look at my post, that's exactly what I did. Instead of benchmarking, I'll remind you that any text-based file needs to be rewritten to update, and it does not support random access.
Zipping such a text-file means rewriting and rezipping the entire stream, and writing that result to disc on every change. That's fine for a datadump in CSV that is imported, but it is not a ideal structure for data that tends to be modified.
Gerry Schmitz wrote: Where else is is it "too big"?
GMail, if the attachment is larger than 25Mb. So yes, would depend on context, wouldn't it?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I wasn't talking to you.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
No, you were posting on a public forum which allows answering even if someone is not talking to you. Legally and technically no problem, and not intended to offend.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Except you usually miss the point / "context" (as in this case) and I have no interest in "debating it" when I wasn't addressing you.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry, you're normally good when answering but in this case, you really are coming across as a jerk. Rather than defending your position, you have made a blanket statement and are being hostile when presented with opinions that you don't like. Eddy presented situations where it's "too big" and you're ignoring him just because he's not the OP; oh, and your point was only a very minor part of what the OP might have wanted to do so you were making assumptions as to the intended purpose, and failed to address the larger issues, which Eddy did.
This space for rent
|
|
|
|
|
I was asking OP to elaborate: in what "context" did he think "his" data was too big. My experience re: JSON was in REST; I was alluding to bandwidth. i.e. the internet. And that browsers generally "zip" unless you turn it off.
Instead, I get addressed as if "I" was questioning said "offendee" about "his" benchmarking? And then he goes off on "email" attachments?
If one waits "a round or two", the context becomes more clear, and you don't come off as a "jerk" by derailing someone else because you're so eager to show "how smart your are".
It's (his) bait; you just can't see it but took it.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: If one waits "a round or two", the context becomes more clear, and you don't come off as a "jerk" by derailing someone else because you're so eager to show "how smart your are".
The hardest part is to get to the first round. I did not intend to be a jerk, but don't mind to be called that either
Gerry Schmitz wrote: It's (his) bait; you just can't see it but took it.
FWIW; there may come a day when we are forced to work on the same team.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I was being rhetorical at this point because Hanlon has already said that I'm the "jerk" here.
And I wouldn't "force" anyone or myself to work with anyone they didn't want to. Or is that what you're used to?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
