On Jun 13, 2007, at 6:13 AM, David Bolen wrote:
> * I want to remove the association between "File Common" and "Job 1" > but without affecting "Job 2". > > If I session.delete() the fc instance directly, SA purges the file > completely, including links to both jobs. I can understand SA > thinking I want the file completely gone in this scenario. > > But if I remove the fc instance from the relation list (files) from > either job, SA also fully purges fc, including the link to the other > job. This includes the case of deleting one of the jobs if I have > the cascade on the files relation including "delete". This would > seem to prevent me from using a delete cascade, since then deleting > any job would remove files it contains from all other jobs also > containing those files which sort of defeats the purpose (at least > for me) of the many to many relationship. If I add this code to the bottom: del j1.files[0] s.flush() the first flush is: BEGIN INSERT INTO files (name) VALUES (?) ['File 1'] INSERT INTO files (name) VALUES (?) ['File Common'] INSERT INTO files (name) VALUES (?) ['File 2'] INSERT INTO jobs (name) VALUES (?) ['Job 1'] INSERT INTO jobs (name) VALUES (?) ['Job 2'] INSERT INTO jobs_files (job_id, file_id) VALUES (?, ?) [[1, 1], [1, 2], [2, 3], [2, 2]] COMMIT the second flush is: BEGIN DELETE FROM jobs_files WHERE jobs_files.job_id = ? AND jobs_files.file_id = ? [1, 1] COMMIT association is deleted only. > > * Providing I can resolve the prior point, I was hoping to have a way > that would let me remove a job completely, including any associated > files, but have the file records only pruned if they did not belong > to any other job. that you have to do manually. cascade isnt going to do that for you. namely, that it requires descending into all child objects, magically producing backreferences to them in order to load their parent objects (in the case backrefs werent defined), then issuing SELECTs for all child objects to determine if they had any other parents. way out of scope. > Am I just missing something blindingly obvious, or should I be trying > to manage the many-to-many relationships, at least deleting, in some > other way? Should I be interacting with the relationship table > directly (but then, how do I remove the files from the contained > project objects without triggering the deletion behavior I don't > want)? if you really wanted to manipulate the relationship table directly, thats fine, but ensure that you expire/refresh the relevant objects and /or clear out the whole session before continuing past that point since SA wouldnt otherwise know you modified relationships behind its back. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
