Forum: Ruby on Rails Has_many, dependent=false, foreign keys legacy issues...

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Eric N. (Guest)
on 2006-05-25 05:05
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?
This topic is locked and can not be replied to.