Rails - May 2006 - Has_many, dependent=false, foreign keys legacy issues...

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?

-- 
Posted via http://www.ruby-forum.com/.