On 09/13/2010 08:32 AM, Michael Bayer wrote: > On Sep 12, 2010, at 11:02 PM, alex bodnaru wrote: > >> thanks a lot michael. >> indeed it works, but it seems counter-intuitive a little since passive_* >> should >> in my opinion be on the side of the on * cascade it describes. >> anyway, it's great, and hope to make it work with elixir too. > If you said session.delete(my_other_object), no action is needed if it > references some particular my_object. It is only if you > session.delete(my_object) that SQLAlchemy needs to do something - and for > that, it must load those objects which reference my_object. It does this > simply by using the one-to-many collection on my_object which states how to > load my_other_objects with an association. So the one-to-many collection > is what's needed here - if you only specified the other direction, SQLAlchemy > would need to derive the forwards collection from it and apply it to the o2m > parent class internally. Right now the internals are simple such that > loading is only possible in the direction in which the relationship() was > configured. > > It is certainly possible to alter relationship() to be able to load > collections or associations in both directions so that a many-to-one > relationship could transparently load from the other direction, though > internally this would require doing pretty much what "backref" does > explicitly - placing some linkage to the relationship on the target class of > the many-to-one which could react to deletions of that target class. So the > current implementation is much simpler than that, so the "passive_updates" > flag goes onto the side of the relationship that ultimately needs it, so that > SQLAlchemy doesn't need to "generate" the backref which is easy enough for > the user to specify, and in very rare conditions may even be configured > differently than the reverse direction. > > The original design of "cascade" is taken from Hibernate, probably the most > widely used object relational tool in history. They too tend to define > ORM-level information about the "foreign key", including the CASCADE > attributes on the primary key side: > > http://docs.jboss.org/hibernate/stable/core/reference/en/html/mapping.html#mapping-declaration-key > http://docs.jboss.org/hibernate/stable/core/reference/en/html/collections.html#collections-mapping > > > > >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To post to this group, send email to sqlalch...@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. >> hope my approach isn't too simplist, but onetomany is usually implemented in rdbms by an manytoone column or a few of them, with or without ri clauses: thus, a foreign key or an index. conversely, a manytoone relation has an implicit onetomany one (or an explicit onetoone).
hereinafter, anything you would define on one end, at least in terms of ri, should be at the end it needs to be there. the example i've given with elixir (look at the sql echo) shows the onetomany updates the foreign key to null, not knowing they wouldn't be found in the cascading delete. i'm searching the exact point elixir should give the passive_deletes to the sa relation, thus to force it to give it to the right side of it. best regards, alex -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
