On Tue, Aug 17, 2010 at 4:29 AM, Edwin Grubbs <[email protected]> wrote: > > If each request knows whether it needs a read-write or read-only > database connection so that it can connect to the slave or master, > couldn't we add the ability for SQLBase to cache all the attributes if > the request is read-only?
This would be interesting to explore, though I have to confess that my mind jumped straight to implementation and I saw two considerations rise up straight away. Firstly is that caching is only a small benefit itself: it saves us doing precisely identical work for the life of the cache. However caching in the model layer is a prerequisite to *prepopulating the caches*, which is where we get the major wins: that lets us eliminate repeated similar work by doing one query for a set of data rather than one query per related thing *per row*. So the gain of caching everything vs caching what we've figured out is safe is relatively small, because the incremental gain from both of these things is small without other work, and that other work will apply to read only and readwrite transactions. Secondly, we need to make internal lookups - self.X - cache, to avoid all db lookups, so we'd need something that can determine whether a particular attribute is dependent only on DB state (which for a readonly transaction we can consider immutable) and then cache it, or whether its dependent on other stuff (like random.random(), for instance). I don't know if thats even possible without some rather -too clever- bytecode hacks. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
