Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

has_many :dependent => :restrict

#1282

Referential databases implementing SQL have a references option to "on delete restrict", preventing a record from being deleted if it has child records.

Rails doesn't have anything like that, and since that's exactly what I need in my project (ie, users with ledger entries should never be deleted), I'm creating a ticket for it.

Patch to follow shortly.

Reported by Steven Soroka · October 27th, 2008 @ 05:29 PM

State: stale
Milestone: 3.x
Importance: none

Activity

  1. Steven Soroka
  2. Marshall
    Marshall

    +1 on the idea. However I think there's a bug if you have other associations with :dependent => :destroy on the same model. See http://lists.rubyonrails.org/pip... for a previous discussion of the problem.

    January 6th, 2009 @ 05:13 AM

  3. Marshall
    Marshall

    I should've posted a bit more information on the problem... if you have :dependent => :destroy on a different association that is defined before the :dependent => :restrict association, then the first association's before_destroy will fire before the restricted association raises the exception.

    January 6th, 2009 @ 05:16 AM

  4. Steven Soroka
    Steven Soroka

    Hmm, good point, I'll have to fix that.

    January 6th, 2009 @ 03:24 PM

  5. Xavier Shay
  6. Xavier Shay
    Xavier Shay

    though it should return false rather than raise I don't quite understand Marshall's problem - all the callbacks happen in a transaction so who cares if the :destroy callbacks trigger first? (aside from maybe performance)

    February 8th, 2009 @ 05:57 PM

  7. Steven Soroka
    Steven Soroka

    Maybe it's a problem because mysql in myisam mode doesn't support db transactions?

    March 9th, 2009 @ 02:52 PM

  8. wildchild
    wildchild

    Quite useful. Any status update?

    March 21st, 2010 @ 07:40 AM

  9. Steven Soroka
    Steven Soroka

    I have some time, I'll take another look at this. I think you'd be fine to use the patch as long as you have transaction support in the database.

    March 21st, 2010 @ 03:30 PM

  10. Jeremy Kemper
    Jeremy Kemper
    • Milestone changed from 2.x to 3.x

    May 4th, 2010 @ 06:48 PM

  11. Ryan Bigg
    Ryan Bigg
    • State changed from new to incomplete
    • Importance changed from to

    Please update this patch to apply to current Rails master and 2-3-stable.

    October 11th, 2010 @ 04:49 AM

  12. Prem Sichanugrist (sikachu)
    Prem Sichanugrist (sikachu)
    • Assigned user set to Prem Sichanugrist (sikachu)

    I think this would be better included in 3.1.

    However, do you think this feature should support non-transactional database engine too? If so, I have to find the way to make the relational checking to be the topmost callback.

    October 11th, 2010 @ 12:12 PM

  13. François Beausoleil
    François Beausoleil

    Couldn't this simply add a validation check before anything else? Then validation will pick the problem, and before_destroy callbacks won't have a chance to fire. This should anyway be complemented with a constraint in the DB.

    I created a duplicate ticket, even though Google didn't return anything useful: #6199 has_many :dependent => :deny

    December 20th, 2010 @ 03:45 PM

  14. rails
    rails
    • Tag changed from 2.2, activerecord, association, has_many to 22, activerecord, association, has_many
    • State changed from incomplete to open

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

    March 21st, 2011 @ 12:00 AM

  15. rails
    rails
    • State changed from open to stale

    March 21st, 2011 @ 12:00 AM