On Jan 10, 2012, at 5:45 PM, Kent wrote: > After 0.7.5 migration, I'm sometimes hitting an issue from within > merge(). > > unitofwork.py > > def track_cascade_events(descriptor, prop): > ... > def set_(state, newvalue, oldvalue, initiator): > # process "save_update" cascade rules for when an instance > # is attached to another instance > if oldvalue is newvalue: > return newvalue > > sess = session._state_session(state) > if sess: > prop = state.manager.mapper._props[key] > if newvalue is not None: > newvalue_state = attributes.instance_state(newvalue) > if prop.cascade.save_update and \ > (prop.cascade_backrefs or key == initiator.key) > and \ > not sess._contains_state(newvalue_state): > sess._save_or_update_state(newvalue_state) > > if oldvalue is not None and prop.cascade.delete_orphan: > oldvalue_state = attributes.instance_state(oldvalue) > # <===== > > if oldvalue_state in sess._new and \ > prop.mapper._is_orphan(oldvalue_state): > sess.expunge(oldvalue) > return newvalue > > > I'm hitting here with an oldvalue of attributes.PASSIVE_NO_RESULT, > which naturally has no instance_state() ! > > So the first question is: is this due to one of my transient loader > hacks or can you think of a path through merge() that you might reach > this set event with an oldvalue of attributes.PASSIVE_NO_RESULT?
Well many-to-ones, when you replace the value, generally don't load the "old" value since it's not needed for the UOW. if you set the active_history=True flag then it will load the "old" value when a new one is coming in. It used to load the "old" value for many years until people complained enough about how wasteful it was. Not sure here of 0.6/0.7 changes, it's very possible the mechanics there have been tweaked. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
