Hi again,
Now using SQLAlchemy r3811, using the code at
http://pastie.caboo.se/121148
In this case, the merge operation do some lazy loading. When
no inheritance is in use, the behaviour is not visible since the lazy
loaded instance are already merged in the session (but the log output
clearly states that some lazy loading is done (1)). When using
inheritance, child tables are queried for each lazy loaded attribute.
Thanks again, Pierre-yves.
(1)
2007-11-23 11:59:40,447 DEBUG sqlalchemy.orm.strategies.LazyLoader
lazy load attribute group on instance [EMAIL PROTECTED]
2007-11-23 11:59:40,448 DEBUG sqlalchemy.orm.strategies.LazyLoader
lazy load attribute user on instance [EMAIL PROTECTED]
On Nov 23, 2007 6:37 AM, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> 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.
>
>
>
>
> >
>
--
Pierre-Yves Strub <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
