On Jun 13, 2007, at 10:44 AM, David Bolen wrote:
> > If the cascade becomes "save-update, delete-orphan", then I get the > behavior where deleting from a single parent job flushes all > associations for the file. Although its true you never get an orphan > that way, files get orphaned "before their time". "orphan" status really only pertains to a single-parent relationship. it was not designed for use in a "collection of parents" sense. > > So, adding the cascade, and then changing your line to del j1.files[1] > (to delete the common file), I get on the second flush: > > BEGIN > DELETE FROM jobs_files WHERE jobs_files.job_id = ? AND > jobs_files.file_id = ? > [[1, 2], [2, 2]] > DELETE FROM files WHERE files.id = ? > [2] > COMMIT > > which is removing the common file association with both jobs, and then > removing the file itself. It's true that after doing the former, it's > an orphan which can be deleted, but I don't know why it's including > the second job in the association pruning. if it deleted from files without deleting all known referencing rows in the association table, youd get a constraint exception. > > On the second point, the complexity of the full cascade recursion with > orphan detection makes sense. I suppose I'm interested in any input > from anyone else as to how they are handling these sorts of operations > in many-to-many cases with changing associations. I would have a backreference on "files" referencing "jobs" and just check that the collection is of length zero..then delete. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
