Jeff Watkins <[EMAIL PROTECTED]> writes: > If we were to try to keep all the necessary information in the cookie, we'd > need an expiry encoded in the cookie (this is how Identity originally > worked). However, because we can't update the cookie without having the > browser ask the visitor to confirm the cookie again, the expiry encoded in > the cookie will eventually pass and your visit will expire -- even if your > last page loaded was seconds before.
I prefer confirming the cookie (the user has to enable cookies anyway, so allow all of them from this specific site nd it is done...) than hitting the DB everytime. It is better to spend user resources than mine. I believe that is is very likely that the user will accept any cookies or accept all cookies from one site after the first or second confirmation. So, problem solved and less load on the DB side. > Additionally, Identity executes 1 SELECT for each request plus another > request if a user is logged in. > > Both of these SELECTs would normally hit the cache, but as I understand it, > SQLObject's caching is problematic. And it a real system, you wouldn't incur > the cost of either SELECT hitting your database. I didn't get this last paragraph... If caching is problematic how in a real system one wouldn't hit the DB if there's no cache? > I believe that by the time TurboGears developers are starting to worry about > 2 SELECTs, they know the environment well enough to tune it by turning off > the features they don't need. I still prefer enabling all cookies from the domain. -- Jorge Godoy <[EMAIL PROTECTED]>
