On Jul 5, 2006, at 4:54 PM, Michael Carter wrote: > normally, i would cache whatever relations are loaded on the object > just the way they are. otherwise you have to cache SQL queries > directly since you cant really predict the full SQL/corresponding > result set that is used to load a relation. you might also want to > just build into get() somehow, which wouldnt prevent a lazy-loading > query from firing off in all cases but would prevent the object > creation step. > > Which get do you think should I build into? >
it sort of depends on waht kind of caching you want. > the whole thing might also be accomplished as a subclass of Session > since you can control object scoping completely at that level, and > you could also stick a straight up SQL cache in there as well since > mapper goes through Session to get the connection its working with. > ive usually been more comfortable with caching SQL directly for > things like this, often turns out to be easier in the end. > > > Are you suggesting hashing the sql queries and using them as keys > to store the result sets would be the best way to go about this, as > opposed to caching individual objects and relations. > caching SQL is generally "easier" to implement. but if you need fine grained ways of mapping individually cached objects back to the SQL that generated them, then its not very easy. > > As for the subclassing Session, is this the sort of thing you had > in mind? > > class CacheSession(Session): > def get(self, class_, ident, **kwargs): > try: > return self.session._get(ident) > except KeyError: > pass > cache_hash = cache_hashkey(class_, ident) > obj = self.cache.get(cache_hash) > if obj: > self.cache.set(cache_hash, obj) > return obj > return Session.get(self, class_, ident, **kwargs) > > If this is what you were suggesting, then the tricky part would be > expiring objects when they are updated. It seems I'd have to get > into the uow.flush function or perhaps loop through session.dirty > and expire all those objects from the cache after calling uow.flush. i would subclass the _get() method most likely. if you need post- flush operations, you probably want to decorate the flush() method itself. caching is a really ambiguous endeavor, if you can lay out your requirements more specifically that would help (specifically, whats the lifecycle of a cached object, and what scenarios are you trying to optimize ? i.e. do you have expensive SQL, etc.) Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
