|
|
Posted by Steve on 04/23/07 15:42
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:dtudnXXVaO9aV7HbnZ2dnUVZ_uPinZ2d@comcast.com...
| Steve wrote:
| > | Actually, David, going to a database won't work any better. You still
| > | need to keep the key to the row in the session, and if you lose the
| > | session you lose the database info.
| >
| > you'd only lose db info if the record is deleted or an update was made
but
| > not committed. the chances of losing a session are present, however
losing
| > data because of that are nil on the delete side and negligible on the
update
| > side.
| >
|
| No, the data is still in the row. But if you lose the session you lose
| the link to the data. It might as well be gone, even if it is committed.
'might as well be' and *is* are not ==.
note that as i've said. the chances of losing data due to deletion is nil.
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).
| > | 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.
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.
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.
| 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.
Navigation:
[Reply to this message]
|