Hi there - there are actually two bugs here, the second one is revealed after repairing the first.
The first bug is that the merge() dont_load operation was not completing all the necessary housekeeping on the newly generated copy of the instance, such that the lazy loader for "zone" (or any other lazy loader) mistakenly detected that the instance had no mapper. this was an easy fix. The second bug is more complex, and its that the committed_state collection for the newly generated copy of the instance contained data from the unmerged copy, in this case the merged User contained the unmerged Address in its committed state. Since the new copy's own "addresses" collection contained the merged Address but not the unmerged one, the flush() would mistakenly update the unmerged address to not have any User object. At the moment I'd rather not get into the added complexity of regenerating a "committed_state" collection on the merged object which corresponds to exact changes made on the unmerged object. since the use case for dont_load=True is cached objects being brought into a session, they shouldn't have any pending changes on them anyway....so for now I have it raising an error if you try to merge an entity that's marked as "dirty", and the newly merged instances get a "clean" committed state. if someone is merging objects with pending changes its really best not to use dont_load anyway so that the committed_state collection represents the most recently available database state. comments welcome on this one as usual. These changes are in r3811. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
