launchpad-reviewers team mailing list archive

[Graham Binns <graham@xxxxxxxxxxxxx>]

> There's one more thing I hope will get someone's attention: the XXX I added.
> I intend to remove it after discussion and resolution in this review.
> 
> Here's the concern.  The filter class
> (lp.bugs.model.bugsubscriptionfilter.BugSubscriptionFilter) has an explicit
> "delete" method that will delete all of its subobjects (that is, records in
> the database in a many to one relationship with the filter class).  However,
> the structural subscriptions do not have any similar code for the filters,
> which are themselves many to one with the structural subscriptions.  Why?  Is
> the delete method in BugSubscriptionFilter overkill because we have cascading
> delete in the database, or do I need to do something similar to the delete
> method on structural subscriptions?  This seems like an elementary question
> for LP development, but not something I've encountered yet.

I don't know the answer to this, I'm afraid. I don't see anything in the DB that suggests we have a cascading delete set up in the database, and IIRC you'll get an OOPS if you try to delete something that has other DB rows hanging off it. My best suggestion would be to write a test for this and see whether smoke comes out.
-- 
https://code.launchpad.net/~gary/launchpad/move-events-to-filters/+merge/48069
Your team Launchpad code reviewers is requested to review the proposed merge of lp:~gary/launchpad/move-events-to-filters into lp:launchpad/db-devel.