Add :dependent => :restricted to has_one and has_many

Big thanks for turning this into a "real" patch, Mike.

Two small comments.

First, the "else" path should be modified to list the :restrict option:

raise ArgumentError, "The :dependent option expects either :destroy, :delete, :restrict, or :nullify (#{reflection.options[:dependent].inspect})"

Second, is ActiveRecord::StatementInvalid the right exception to raise here? I threw that in to my sample code just because it's what would be raised by a DB foreign key that restricted deletes. But this isn't technically an invalid SQL statement. Is it worth creating a new exception class for this?

Yup we should have a new exception here.

I'll test the patch on an app today, and add a new exception - ActiveRecord::DependentRecordError or something like that.

Here's the revised patch

Good, there are common use cases for this. Just some minor details:

• The title of the ticket itself reads :restricted :-).

• There are a couple of places where docs say "If the association is marked as :dependent => :restrict, create a callback that prevents deleting entirely.". That's true if there exists children, otherwise deletion is performed.

• I think it could be good to document ActiveRecord::DeleteRestrictionError somewhere, because now destroy may throw it.

• I'd prefer not to load the parent record in has_one to check if it exists, but there is no API for that it would need to be done by hand I guess. (Just a remark... no sure it is worth the trouble, I have in mind exists == @target || select 1 or something in that line).

• There's also a case in HasOneAssociation#replace that I think should say something about :restrict. I don't really remember what's the purpose of #replace. The premise is that child records are untouchable, so an exception would make sense. You are not deleting the parent though, but you do not have information about how to destroy the child either. I think what to do is not completly clear, but I believe raising the exception is sound.

+1 on idea but patch (v2) does not apply on neither master or 2-3-stable. i've attached a patch for both, please note that i had no idea how to credit mike for the entire thing, so my name is up there should be changed to mike before committing

@xavier, your 4th point is something that i having running around in the past few days.. the fact that there is no way to access an associated model from within a reflection / association scope. There are many tickets that share this basic problem, this #3027 Association Table Names Incorrectly Generated when set_table_name used ticket would be easily solved if there was any kind of access to the associated model (and therefore AR::Base.table_name).
Solving this issue can clear some significant amount of tickets.