Hi Ron -- The eventlist is populated by a database query that returns the ids of a set of objects. The "prev" and "next" page flips thru the database ids one at a time and allows adding objects through the database entry. It's a little complicated. The application is a signup app for a high-school swim meet, and each database id represents one event. At each event, users (coaches) are allowed to add records that represent swimmers signing up for that event.
I don't believe it matters how the eventlist is created -- it's just a Python list object containing strings or integers (not at the same time -- I tried each to see if it affects the session var). It is established once when the coach clicks on the meet he wants to sign up for, and then does not change until he chooses another meet. The problem is that the user gets logged off sometimes when "next" or "prev" is clicked. My guess is that something in the session variable is not "pickleable" and is causing the session read-back to fail, thus forcing the re-logon and loss of the session vars. But I've been careful to not add anything but simple Python objects to session vars. (At least that I can find!) -- Joe B. P.S. Good tip on the URL and "int". I just converted from using ints to strings and didn't think thru the URL function. You're probably right -- I'll bet it converts to str when it emits which will save me the int call. On Mar 3, 10:50 am, ron_m <ron.mco...@gmail.com> wrote: > Is eventlist constant for the application? If so put it in the model or if > in a module use local_import. Then all you need in session is the current > index into the array the user is at. > > If eventlist changes then there is no code showing how it is manipulated so > it difficult to help. I would also believe that a variable eventlist would > be difficult to debug. > > On the redirect call above I am not sure why you are converting > session.eventlist[tmp] to an int. It might be converted back to a str by the > URL function but for sure it ultimately ends up as part of a larger string > to form the full URL. > > Finally are users opening the application more than once from the same > client PC? If so the same browser tabs/windows will all use the same > session. Also not sure if this is a problem but are the users behind a NAT > box (typical of small office and home routers) and the server is elsewhere > because this will put all the PCs behind the NAT at the same client IP which > I believe causes sessions to be shared.
