|
|
Posted by Steve on 04/23/07 22:45
"Gordon Burditt" <gordonb.okqym@burditt.org> wrote in message
news:132qc2s2mle061e@corp.supernews.com...
| >data is in the db. a query will return the correct step that is next in
the
| >ladder of steps to get to the top. user logs back in, that step is
| >displayed. now, pray-tell, HOW IS THE DATA LOST?
|
| Your database will gradually collect abandoned sessions. Users
| tend not to use "logout" buttons. You might ask a hard question
| that requires research. People get called into meetings. Users
| click on an ad and don't come back. Browsers crash. OSs crash.
you state logout, so i assume login is required in your dismal scenario
here. the tie-in here of course would be answered with $userName.
| Your user returns. You didn't get him to log in, so there's no
| such thing as a "user name". The session key is lost. How do
| identify which session is his? There are 87 sessions abandoned at
| step 1, 37 sessions abandoned at step 2, 55 sessions abandoned at
| step 3, 14 sessions abandoned at step 4, and 5 abandoned at step
| 5. Which step do you restart at, and using which set of data?
so now there is no $userName. either consider it abandoned if the session
key is lost, or if it is important enough, make a log in required script.
even so, there are many a means to generate a unique id without a log on
that comes pretty close be assuring the client returning is in fact, the
client.
fact of the matter is, you still are NOT showing one set of architecture as
being better than any other. all of these issues STILL EXIST if you keep all
data sessioned and lose the sesssion. if there is a login, that's no big
deal...you know what data belongs to whom. if it's shared data (i.e. a part
being built up at a station) then identifying the station at which work
would be done will give you a list of things currently being built that you
can state you're working on. otherwise i'll relent, you're in the same boat
as sessioning...however there is far more flexibility in db driven steps
than sessioned steps...such as being able to work a part with multiple
employees (which is often the case).
| >| > note that as i've said. the chances of losing data due to deletion is
| >nil.
|
| Losing data due to hiding it like a needle in a needlestack is
| losing it even if you can still prove it's in there somewhere.
and how does sessioned data prevent any of this. how does this go to show
that db driven steps are equal in architectural flexibility. it simply does
not.
|
| >| > what you've described is what i also noted. that an update can cause
a
| >| > partial loss of data but this only involves the data related to the
| >current
| >| > step, and is therefore negliable (with a few caveats).
| >| >
| >|
| >| No one ever said anything about deletion or update. I was specifically
| >| talking about losing the id to the row which is stored in the session -
| >| and the session is lost. Nothing more, nothing less.
| >
| >data is in the db. a query will return the correct step that is next in
the
| >ladder of steps to get to the top.
|
| When you have 198 abandoned sessions, what does the WHERE clause of that
| query look like to find the correct one? Oh, yes, there may be severe
| privacy implications of showing them all the sessions and letting them
| pick one.
|
| Also, if you've got that many abandoned sessions, it's probably easier
| for the user to just start over rather than read all of them. That's
| "buried in bullshit" lost.
same as i've just said above. there are ways to identify and reclaim the
appropriate records that need editing. it really depends on the business
requirements. i can tell you that i can scale db driven steps whereas you
cannot say the same for sessioned data. you'd also have a hell of a time
sharing the data between multiple clients sessioning data.
both of you still have NOT answered the op's direct question about how to
SOLVE DROPPED SESSIONS. i point him to what to look for. further, that it is
a better fallback to db the inputs rather than session them. again, you two
still have NOT shown that both methods are equal. either of you still have
not layed out a solid, concrete real world scenario that demonstrates
sessions as superior.
i'll wait for that.
Navigation:
[Reply to this message]
|