Posted by Gordon Burditt on 04/23/07 22:17

>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.

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?

>| > 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.

>| > 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.

>user logs back in, that step is
>displayed. now, pray-tell, HOW IS THE DATA LOST?


>
>| > | > | If you force them to sign in, you could key the data to their user
>id;
>| > | > | then at least it would be saved when the session fails. But then
>| > | > | they'll have to log in.
>| > | >
>| > | > and when the user logged in again, since the data is in a db rather
>than
>| > a
>| > | > session, you could bring them to the last step they completed
>(whether
>| > there
>| > | > is already some populated data they hadn't completed or if they're
>at
>| > the
>| > | > beggining of that step).
>| > | >
>| > |
>| > | And you'll have another session id and another key, unless it is keyed
>| > | to the userid, as I mentioned above. But he still has to login
>because
>| > | the session disappeared.
>| >
>| > yes, the re-log in is a bitch. however i don't recall either you or i
>| > addressing this problem. let's stick to the architecture for a moment
>then.
>| >
>|
>| It's part of the architecture - and something the op wants to avoid.
>
>then wtf don't you just address how he can solve the session problem instead
>of giving BAD architectual advice...like, 'a db won't get you any closer to
>solving the problem'. as i've pointed out, it DOES allow for a way to
>recover. you just have no idea how to implement a fail-safe.
>
>get over it.
>
>| > don't couple specific data to a user. we don't have to here. if you want
>to
>| > detect the last thing a user was working on, so be it. however nothing
>says
>| > that has to be that way. you may not even see that as desireable though.
>| >
>| > let's say i work at station 4, take lunch but have left a component to
>be
>| > finish by someone else at station 4. after my lunches i begin working at
>| > station 5. station 5 is where the build up of astronautic rocketry is
>| > performed, while station 4 is where legos are put together to keep all
>the
>| > workers humorous and sane.
>| >
>| > you don't want to tie the user data to a step here. what could be done
>is
>| > allow a login with a selection of stations from which he can chose to
>work.
>| > it would then be appropriate to begin the completion of the most current
>| > work. that could be automatic, or if multiple components are built up
>there,
>| > they could put in a job id, part id, or any other identifier. having
>THAT
>| > identifier pull from already SAVED data will solve a bunch of problems.
>| >
>|
>| Let's stick to the architecture for a moment then. No one ever said
>| anything about changing stations, for instance.
>|
>| > and btw, NONE of these altertatives i just described are available
>WITHOUT A
>| > DB. the ONLY thing one should ever need to session is the logon
>information
>| > of the user. anything else is bad architecture.
>| >
>|
>| If there even is a session login. That part is not clear.
>
>in the architecture *i've* described, NO LOGIN NEED BE PRESENT. as i said,
>if you simply select what work you'd like to begin, having a DB will allow
>you to query DATA for what is left to do for the task. even without a login,
>identifying WHERE the user is performing his job (answering questions/giving
>input), you'd be able to give them a LIST of incomplete tasks from which
>they could pick.
>
>sessions WON'T allow you to do that. a DB will...with great flexibility in
>ANY context however you implement your access to a process per user. if you
>remember, you said a db essentially does shit for the op's problem. you
>clearly see i beg to differ.
>
>| > | And if the op isn't forcing the user to login, there is no way to sure
>| > | way to identify the data.
>| >
>| > i think i just described a litany of ways in which your assertion here
>is
>| > utterly foundless.
>| >
>| >
>|
>| You have? I don't see it. All I see is a bunch of rambling about
>| completely unrelated possibilities.
>
>then you're mind is wholly inable to imagine the TYPE of general
>functionality the op wants AND can't draw from you previous EXPERIENCE to
>correlate different solutions that are applicable to the TYPE.
>
>intellect is measure by inference and association. are you saying you truly
>see NO similarities between my 'ramblings' and what the op is doing? if not,
>i feel for you, bro.
>
>| The fact is, if you lose the key to your row, you can't access that row.
>
>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?
>
>

[Back to original message]