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?