|
|
Posted by Jerry Stuckle on 04/23/07 17:22
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.
> 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.
> | > | 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.
> 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.
> | 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.
The fact is, if you lose the key to your row, you can't access that row.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|