On Jul 24, 2009, at 10:33 AM, Michael Bayer wrote:
> > Michael Bayer wrote: >> >> Victor Lin wrote: >>> >> It is a TODO within SQLAlchemy for this particular operation to not >> trigger an unnecessary load. >> > > > I've added a patch as well as your test as > http://www.sqlalchemy.org/trac/ticket/1483 to address the > unnecessary load > issue. It needs more testing to ensure things don't go wrong, but > feel > free to apply said patch to your 0.5.5 copy if you want to experiment. > I'll try to test further this weekend. OK , somewhat bad news on this front, the test you have needs to do what its doing. Here's why: first, make a User with a Site: v = User(name='victor') s1 = Site(title='s1') v.site = s1 sess.add(v) sess.commit() everything is fine there. the commit() expires everything. now make another site, and hook it up. s2 = Site(title='asdf', user=v) sess.add(s2) sess.commit() when you associate s2 with v, the ORM *must* locate the previous "s1" row from the database, since you've set this up as one-to-one. the previous "s1" row needs to be deleted and the ORM only knows that because the action of setting s2.user hits the User.site backref, which properly loads the previous row and queues it up for deletion. the usual use case for "delete-orphan" cascade is on a many-to-one, its unusual for it to be set on the non-foreign key side of a one-to- one. so while I still may do something with 1483, this specific case can't change. --~--~---------~--~----~------------~-------~--~----~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
