This project is archived and is in readonly mode.

#2954 ✓stale
jd

test_postgresql fails on brand new Edge Rails: RI_ConstraintTrigger related error

Reported by jd | July 25th, 2009 @ 09:08 AM | in 3.x

Hi.

I've just cloned Edge Rails from github. Once mocha gem installed, rake seems to run smoothly but with postgresql. While in the activerecord folder, I ran rake postgresql:build_databases and even had GRANT ALL on the activerecord_unittest* databases for both myself and rails user. I attach a log from the command "rake test_postgresql > output.log" (featuring some French error sentences inside, sorry).

I hope I did not forget something meant to be obvious (say, a gem dependency?) :)
Thank you.

Comments and changes to this ticket

  • jd

    jd July 25th, 2009 @ 09:13 AM

    Here's a truncated log.

  • jd

    jd July 26th, 2009 @ 01:28 AM

    I found a workaround for this issue. A Foxy Fixtures patch issued on 2007 tackles the problem. I did a research in Lighthouse but it seems everybody is running pg fine with superuser privileges since there is no occurrence for this error :)

    http://kopongo.com/2008/7/25/postgres-ri_constrainttrigger-error#co... is also a valuable resource, and http://schuerig.de/michael/blog/index.php/2007/11/08/testing-with-f... may be useful as well.

    So basically, if the pg user used to run the tests on activerecord_unittest* databases does not have superuser privileges, the current implementation of Active Record PG adaptater will fail with a PGError related to disabling/enabling triggers. There seems to be two solutions:
    - run rake test_postgresql with a pg superuser-granted account; - in activerecord/lib/active_record/connection_adaptaters/postgresql_adaptater.rb, alter 451-460 to:

    def disable_referential_integrity(&block)
      transaction {

    begin
      execute "SET CONSTRAINTS ALL DEFERRED"
      yield
    ensure
      execute "SET CONSTRAINTS ALL IMMEDIATE"
    end
    
    
    
    
    } end
    This however makes supports_disable_referential_integrity() useless, so I guess refactoring would be preferable if a patch is needed. For the moment, it suits my needs (that is passing the tests) and I don't know if a patch is actually needed: is it a bug or a feature?

    I then wonder: must I make my pg user a superuser if I am to contribute to Edge Rails? This seems strange to me as it's a bold requirement, but maybe that's the standard way to go (not really obvious reading the documentation though).

    Also, I'd like to know if there is a privileged place to set a require 'my_workaround_for_postgresql_triggers' so rake test_postgresql runs. For the moment, I just edited my clone lib file, but that's lame :) Maybe I'll go for a pg superuser in the end…

  • jd

    jd July 26th, 2009 @ 07:12 AM

    • Assigned user set to “Tarmo Tänav”
  • Tarmo Tänav

    Tarmo Tänav July 26th, 2009 @ 02:01 PM

    Hi,

    A while ago I used to use the deferred constraints approach too but obviously we can't rely on it because it only works if the constraints are actually set up to be deferrable and that is something we can't require nor detect at this point.

    Also, this is actually less relevant to contributing to edge rails (as AR test data does not contain FK constraints) and more relevant to developing rails apps that use FK constraints. For developing rails it seems reasonable for me to require super user privileges, for developing rails apps I do remember some people who had to use a database outside their control (and thus no superuser privileges) and for them this obviously is a problem, but I'm really not sure how to solve this.

    One thing that should make things better for people who don't use FK constraints would be to not disable triggers if the database does not have FK constraints, but before we can do that we need support for introspecting those constraints.

    As for you, I'd suggest going the superuser route for now, unless you have complex privilege rules which your rails apps must be able to work with or are running this on a production database it should be fine.

  • jd

    jd July 27th, 2009 @ 03:17 AM

    Thank you for this rather complete answer.

  • Jeremy Kemper

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

    • Milestone changed from 2.x to 3.x
  • pedz

    pedz June 11th, 2010 @ 04:40 PM

    This has been an issue for many years. I wish it would get fixed. No, it is not reasonable to require super user privileges just to develop rails. I understand that most Rails users do not understand constraints but the belief that Rails can protect the database from corruption has never been true and never will be true. Indeed there are comments in the Rails code to this effect.

    I put this (along with a few other snippets) into config/initializers/patches.rb

    module ActiveRecord
    module ConnectionAdapters

    class PostgreSQLAdapter
      def disable_referential_integrity(&block)
        transaction {
          begin
            execute "SET CONSTRAINTS ALL DEFERRED"
            yield
          ensure
            execute "SET CONSTRAINTS ALL IMMEDIATE"
          end
        }
      end
    end
    

    end end

  • Santiago Pastorino

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

    • State changed from “new” to “open”
    • Importance changed from “” to “”

    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:37 PM

    • State changed from “open” to “stale”

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>

Attachments

Pages