After reading the archives, I''ve come to the conclusion: If you have a one-to-many relationship, the correct Rails way to ensure that the "many" records are deleted when the "one" is deleted is to use :dependent => true, and not to use ON CASCADE (except perhaps for belt- and-suspenders), because of DRY. If you have a many-to-many relationship, the correct Rails way to ensure that the join-table records are deleted is to use ON CASCADE, because there is no :dependent clause. 1. Am I right? 2. Does this inconsistency merit a bug? -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
Jay Levitt wrote:>After reading the archives, I''ve come to the conclusion: > >If you have a one-to-many relationship, the correct Rails way to ensure >that the "many" records are deleted when the "one" is deleted is to use >:dependent => true, and not to use ON CASCADE (except perhaps for belt- >and-suspenders), because of DRY. > >If you have a many-to-many relationship, the correct Rails way to ensure >that the join-table records are deleted is to use ON CASCADE, because >there is no :dependent clause. > >1. Am I right? > >2. Does this inconsistency merit a bug? > > >http://dev.rubyonrails.org/ticket/2015 ? -Robby
Robby Russell wrote:> Jay Levitt wrote: > >> After reading the archives, I''ve come to the conclusion: >> >> If you have a one-to-many relationship, the correct Rails way to >> ensure that the "many" records are deleted when the "one" is deleted >> is to use :dependent => true, and not to use ON CASCADE (except >> perhaps for belt- >> and-suspenders), because of DRY. >> >> If you have a many-to-many relationship, the correct Rails way to >> ensure that the join-table records are deleted is to use ON CASCADE, >> because there is no :dependent clause. >> >> 1. Am I right? >> >> 2. Does this inconsistency merit a bug? >> > http://dev.rubyonrails.org/ticket/2015 ?Doesn''t seem to address the point - it just makes the inconsistency worse, because there''s still no :dependent on HABTM, but the :dependent relationship available on has_many becomes richer. -- Alex
In article <4325AFD2.2020302-/Lcn8Y7Ot69QmPsQ1CNsNQ@public.gmane.org>, robby.lists-/Lcn8Y7Ot69QmPsQ1CNsNQ@public.gmane.org says...> >If you have a many-to-many relationship, the correct Rails way to ensure > >that the join-table records are deleted is to use ON CASCADE, because > >there is no :dependent clause. > > > >1. Am I right? > > > >2. Does this inconsistency merit a bug? > > > > > > > http://dev.rubyonrails.org/ticket/2015 ?That doesn''t seem to cover habtm, though... -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
On 9/12/05, Jay Levitt <jay-news-WxwZQdyI2t0@public.gmane.org> wrote:> After reading the archives, I''ve come to the conclusion: > > If you have a one-to-many relationship, the correct Rails way to ensure > that the "many" records are deleted when the "one" is deleted is to use > :dependent => true, and not to use ON CASCADE (except perhaps for belt- > and-suspenders), because of DRY. > > If you have a many-to-many relationship, the correct Rails way to ensure > that the join-table records are deleted is to use ON CASCADE, because > there is no :dependent clause.There are three tables in a habtm relationship: the table for class1, the table for class2, and the join table that links them together. When you call class1.destroy, the join table records are deleted automatically by rails via the before_destroy callback. Any class2 records are (appropriately) left alone.