Patrick Lewis wrote:
Also note that updating the Visit table's expiry is performed in the background by queuing the request and then processing it after a timeout. This allows for optimizations like only updating the table once even if the user has hit five new pages since the last time the queue was processed.On Mar 4, 5:02 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:On Mar 4, 1:38 am, Patrick Lewis <[EMAIL PROTECTED]> wrote:In SQL it would be something like SELECT count(*) FROM visit v Inner join visit_identity vi on v.visit_key=vi.visit_key Where vi.expiry > current_timestamp Basically, check for visit sessions that haven't expired.Are you saying the Identify framework keeps track of how much time has elapsed since the last activity? And, if greater than some value it pronounces it "expired"? I didn't know the authentication components could detect every interaction and do that. Seems like a lot of work to start a stopwatch after every client request.It's not really a stopwatch, per se. On every new visit, the 'expiry' field in the Visit table is set to the current time plus the number of minutes defined in your visit.timeout config variable. When you next visit the site, turbogears gets your visit cookie and uses it to compare the current time to the expiry time in the database. If the current time is later than the expiry time, a new cookie / visit session is generated, and you are essentially logged out of your previous session. If it is before the expiry time, the visit table expiry field is updated with a new value of timeout + current time.
-Toshio
signature.asc
Description: OpenPGP digital signature

