I'm playing around with some legacy schemas; ones that make extensive use of foreign key update/delete rules. I've been working through a variety of cases to understand how different configurations within Rails will play with the DB. If the delete rule is Cascade and :dependent=>false, deleting the parent deletes the children, exactly as the DB rules specify and do so efficiently (of course by-passing any actions attached to the model....) If the delete rule is Restrict and :dependent=>false, deleting the parent yields an exception (as expected..) Ie, most of these cases make sense and appear to "just work", changing to dependent=>true, works in a predictable way (even if it might not make sense from the data modellers perspective) The only place where I feel like rails lets me down is: rule is cascade, dependent=>false, foreign key column has a not null constraint (and schema.rb shows that it knows about the not null constraint) p.children.delete(p.childrenp0]) throws up an exception from straight from the DB. I can understand why it doesn't chose to delete the row because Rails has been told its not dependent. However, I would have hoped that the exception could have been thrown from earlier in the call stack -- ie AR should know that the delete is going to fail. From the developer POV it doesn't really matter, but it seems to suggest that Rails doesn't use the null=>false information to its benefit.... So generally speaking it looks like in legacy settings one should _alwasy_ use :dependent=>true with Cascade rules and careful thought is needed with Restrict rules?
on 2006-05-25 05:05