Rails Ruby on Rails → 3.x

Comments and changes to this ticket

• You flagged this item as spam.
  

  jd July 25th, 2009 @ 09:13 AM

  Here's a truncated log.

  • output.log 57.1 KB

• You flagged this item as spam.
  

  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…

• You flagged this item as spam.
  

  jd July 26th, 2009 @ 07:12 AM

  • Assigned user set to “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.

• You flagged this item as spam.
  

  jd July 27th, 2009 @ 03:17 AM

  Thank you for this rather complete answer.

• 

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

  • Milestone changed from “2.x” to “3.x”

  [bulk edit]

• You flagged this item as spam.
  

  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 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 February 2nd, 2011 @ 04:37 PM

  • State changed from “open” to “stale”