Posted by Jerry Stuckle on 04/23/07 22:34

Steve wrote:
> "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?
>

WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
ABOUT THE USER LOGGING IN!

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

ONLY IF YOU HAVE THE PRIMARY KEY TO THE COLUMN!!! IF THERE IS NO LOGIN,
HOW DO YOU DETERMINE WHICH ROW IT IS?

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

THEN GET OVER IT! THE ARCHITECTURAL ADVICE IS SOLID! AND YOU HAVEN'T
POINTED OUT ANYTHING EXCEPT "IF THE USER LOGS IN...".

And that does solve the problem of the user having to log in.


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

THEN HOW DO YOU DETERMINE WHICH ROW IS ASSOCIATED WITH THAT USER? HOW
DO YOU KNOW WHICH TASKS ARE COMPLETE AND WHICH ARE INCOMPLETE?

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

SESSIONS KEEP TRACK OF WHICH ROW IN THE DATABASE IS BEING REFERENCED.

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

And your mind is completely unable to grasp a simple concept. If the
session is lost and there is no user login, there is no way to reference
the row in the table related to this user.

You have 500 users currently active. Suddenly one of them loses a
session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
USER? THERE IS NOT LOGIN!

And YES I'M YELLING. You don't seem to grasp even a simple concept.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]