On Nov 2, 2007, at 1:15 PM, klaus wrote:
> > Thanks, but this doesn't seem to do what I wanted. The merge modifies > the object and therefore tries to update the underlying table on > session.flush(). So it might work if you prevented the save also. OK, ive committed the patch plus a fix + test for that specific behavior to the trunk. If you try out the trunk, youll see that you can merge(x, dont_load=True) and the objects get copied into the session with the same "commited" state as the incoming object; so that if no changes are present against the incoming object, no changes will be tracked on the merged version either. > I would prefer a solution, though, that allowed these objects to be > immutable like their tables. That is, copy.copy could be used but no > constructor and no setattr/delattr (and no remove). My implementation > currently catches these with a NotImplementedError. "immutable" to me is a class behavior, so thats out of the SQLAlchemy realm IMHO. the merge() with dont_load right now will copy the committed state of the incoming object so it should act the same as the cached object. copy.copy() is not smart enough here since it cant detect child objects which are already present in the session (which is the issue youre having). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
