This project is archived and is in readonly mode.

#2693 ✓stale
Victor Nawothnig

Removal or Rewrite of disable_referential_integrity in AR

Reported by Victor Nawothnig | May 22nd, 2009 @ 12:18 AM | in 3.x

I suggest to remove disable_referential_integrity(&block) from all the adapters in ActiveRecord or redesign the specific behavior.

Even though I just submitted a patch to correct the conditions which can leave the database in inconsistent/erroneous states, I do not think that this method should exist in the way it is right now.
This opinion is shared by people in #postgresql on freenode.

Even though I suggest removal or redesign of all entities of this method (not just of the PostgreSQL-adapter) the reason stays the same.

It makes no sense to disable RI for any reason, at least not in the way it is handled. If the block is executed, the referential constraints are not checked against the new data (updated or inserted). Thus the best way for this would be to completely drop the constraints, yield the block and create them again.

If bad data (incorrect references) have been inserted, creating the constraint would fail, which would ensure database consistency.

I can write a new method which drops the constraints (if necessary other constraints too as well as indexes or other things), yields the block and then creates them again.

Also I'm curious as to what purpose this method serves? Right now I assume that the sole purpose is to insert large bulks quickly without the constraint being checked on each row.

Something like:

disable_referential_integrity {
populate_tables_with_lots_of_data() }

However, the best approach for exactly this would be as stated to remove the constraints (and especially indexes), insert the data, and recreate those constraints + indexes. I'm not sure about MySQL but this would be the only way to do things in PostgreSQL.
(A re-index is not a good option, usually a create index is faster if large bulks of data have been inserted).

So what do you think?

Comments and changes to this ticket

  • Jeremy Kemper

    Jeremy Kemper May 4th, 2010 @ 06:48 PM

    • Milestone changed from 2.x to 3.x
  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:51 PM

    • State changed from “new” 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.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:51 PM

    • State changed from “open” to “stale”
  • bingbing

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Tags

Pages