if i get it right, u make some "map" in memory of that terra incognita of those untouchable readonly objects, and then use it ? so why not just build all that _once_ into some structure of non-DB objs, and then throw away the DB-related? or maybe even incrementaly?
On Monday 02 June 2008 18:55:03 Nebur wrote: > > im assuming the performance increase is due to the reduced > > overhead in creating objects ? From what I can see, you are > > still issuing SQL, still processing result rows, still populating > > state in the given instances....all of which is very time > > consuming. Plus, your scheme actually wont even save object > > creation overhead since you can't exactly do it that way... > > That's right: The queries are the same when no futher optimization > is applied. Object creation surely is very fast when compared with > queries. > But there have been two intentions: Performance, and object > identity. Performance is not significantly improved by saving > object creation. But the results of some performance critical > methods are cached, thus saving a huge amount of queries. This > caching in turn relies on the constant object identities and would > be tricky if the objects would change their identity. > So, the performance improvement is an indirect effect. The object > identity simplifies (at least) this task. > > > this wont work out of the box because a particular object > > instance can only be in one Session at a time. For this kind of > > use case we provide a method called "merge()" which takes a > > dont_load=True argument to create local copies of objects in > > sessions. > > Yes, the "custom identity map" cannot be a sessions identity map, > it is a plain dict. Otherwise, the objects indeed would have to be > merged in any new session. But copies of the objects, anyway, are > not desired since identity is to be kept. > > > why not session.new ? "context.uow.new" is gone in 0.5. > > Thanks. ouw.new indeed did not look adequate. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
