On Sep 19, 2011, at 4:09 PM, JPLaverdure wrote: > Hello, > > I'm using the versioned objects suggested in the SQLAlchemy examples: > http://www.sqlalchemy.org/docs/orm/examples.html#versioned-objects > > One of the aspects of entity management seems a bit weird though: > If entities are linked using foreign keys, (let's say in one-to-many > relationship), deleting the "parent" will indeed delete the children (because > of the "on delete cascade" clause) > but the last state of the children will NOT be saved in the _history table of > the children So I basically lose the last state of the children. > ie: the parent _history is saved but none of the children are. > > I of course solved this by running a delete on all children prior to deleting > the parent but as my model grows in complexity, I would sure love for all of > this to be done "automagically". > in other words for versioned_meta to follow foreign keys and mark and linked > entities them as modified as well.
The deletion should be hit if you delete the "parent" via session.delete(parent), and don't have passive_deletes=True on the relationship; it would load in the child objects and mark them deleted individually, thus making them available in the "deleted" list to the versioned listener. Otherwise if you're relying on the DB to emit the deletes via FK cascades or otherwise are using an aggregate DELETE statement, then you aren't going to get them in the "deleted" list during a flush. The core assumption of the example is that you're implementing versioning at the application level, instead of at the trigger level where behavior would be more comprehensive. -- 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.
