Posted by Steve on 04/23/07 17:00

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:l82dnX_3f4PHQLHbnZ2dneKdnZydnZ2d@comcast.com...
| Steve wrote:
| > "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 ==.
| >
|
| The data is lost. It still exists, but there is no way to identify the
| correct 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?

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