Many people wasting their energy about EARLY OPTIMIZATION, THE ROOT OF ALL EVIL :-/
If what matters for you is quickstart behaving well, just use stable version released by Kevin. If what matters is having a good visit tracking or authentication framework, either help Jeff or build your own. Moreover SQLObject itself should mature before people think about caching rowsets etc. Sure caching is good, but nearly always good SQL requests are the most important thing for performance. Jeff: may be turning Visit and Ident filters off by default, and only enabling them in dev.cfg or the controler code would draw much less bullets on you ;-) P.S. A very good tool to cache data is memcached. Enterprise class solution with very low cost and requirements. Jorge Godoy wrote: > 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. > > >
signature.asc
Description: OpenPGP digital signature
