Re: why a session-based program behaves different on different computers

Steve wrote:
"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message news:l82dnX_3f4PHQLHbnZ2dneKdnZydnZ2d@xxxxxxxxxxxxxx
| Steve wrote:
| > "Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
| > news:dtudnXXVaO9aV7HbnZ2dnUVZ_uPinZ2d@xxxxxxxxxxxxxx
| > | 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 *** 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@xxxxxxxxxxxxx
==================
.

Quantcast