> 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 -~----------~----~----~----~------~----~------~--~---
