ConnectionNotEstablished when calling has_paper_trail

[cout]

I get a ConnectionNotEstablished error when I call has_paper_trail from my model. The problem seems to be that primary_key() cannot be called before there is a connection. The solution to this is not obvious. Refactoring the call would at least make it possible to monkey-patch paper_trail in my application.

/home/cout/.rvm/gems/ruby-1.9.3-p194@obis-bridge/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:404:in `retrieve_connection': ActiveRecord::ConnectionNotEstablished (ActiveRecord::ConnectionNotEstablished)
from /home/cout/.rvm/gems/ruby-1.9.3-p194@obis-bridge/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_specification.rb:170:in `retrieve_connection'
from /home/cout/.rvm/gems/ruby-1.9.3-p194@obis-bridge/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_specification.rb:144:in `connection'
from /home/cout/.rvm/gems/ruby-1.9.3-p194@obis-bridge/gems/activerecord-3.2.8/lib/active_record/model_schema.rb:223:in `table_exists?'
from /home/cout/.rvm/gems/ruby-1.9.3-p194@obis-bridge/gems/activerecord-3.2.8/lib/active_record/attribute_methods/primary_key.rb:75:in `get_primary_key'
from /home/cout/.rvm/gems/ruby-1.9.3-p194@obis-bridge/gems/activerecord-3.2.8/lib/active_record/attribute_methods/primary_key.rb:60:in `reset_primary_key'
from /home/cout/.rvm/gems/ruby-1.9.3-p194@obis-bridge/gems/activerecord-3.2.8/lib/active_record/attribute_methods/primary_key.rb:49:in `primary_key'
from /home/cout/.rvm/gems/ruby-1.9.3-p194@obis-bridge/gems/paper_trail-2.6.3/lib/paper_trail/has_paper_trail.rb:71:in `has_paper_trail'

[cout]

I was able to work around this with:

Version.primary_key = 'id'
has_paper_trail

I still maintain that it is undesirable to impose a limitation on the model that it cannot be required until a connection has been established, given that ActiveRecord itself has no such limitation.

[batter]

@cout - Under what circumstances did you run into this? Were you trying to run a rake task or something?

Looks very similar to rubygems/bundler#1946. Looks like the solution may be to update the i18n-active_record to the latest version? Can you try that and see if that fixes the issue?

[cout]

The following snippet is sufficient to trigger the exception:

require 'active_record'
require 'paper_trail'

class Foo < ActiveRecord::Base
  has_paper_trail
end

Although it is the same exception, I'm fairly certain this has nothing to do with the bug you referenced. The i18n-active_record gem is nowhere in the exception pathway. The problem has to do with calling primary_key() when there is no active connection to the database. Setting @primary_key explicitly prevents the exception from getting raised.

I see three options:

• since there's an easy workaround and I'm the only one experiencing this bug, just let me work around it
• stop calling primary_key since you already know what the primary key is for the versions table
• lazily-evaluate the has_many relationship after there is already a connection to the database (afaict, active_record does not supply a hook for this).

[batter]

It looks as though ActiveRecord has not made a connection to the database yet in your example, which is causing the error to be thrown. That being said, after reviewing your suggestions, I question whether it's really necessary to sort ascendingly by primary_key at all, since it is really the timestamp field that we want to sort by (and it is already the first sort criteria anyways).

@airblade - is there an explanation for why the versions association on a model which has_paper_trail is sorting secondarily by the primary key? Here is the line in question. Any reason why that can't be removed from the :order criteria? The tests all seem to pass with it removed.

[airblade]

@batter I'm almost certain you can drop the secondary sort on the primary key. I think I put it in there originally to split ties between version records created with the same timestamp. But I've had a nagging feeling for a while that it's unnecessary -- solving a problem that doesn't exist.

[batter]

@cout - Just out of curiosity, in the scenario where you encountered this, were you attempting to use PaperTrail outside of Rails? I only ask because it seems to me that the has_many relationship is lazily-evaluated, in the sense that the module that defines the has_paper_trail method gets included into ActiveRecord with via ActiveSupport's on_load hook method.

As far as I can tell, that gets called after ActiveRecord has instantiated a connection to the database in the rails boot cycle, so it would not be encountered if using PaperTrail in Rails as the documentation outlines. That being said, we are exploring the possibility of supporting usage of PaperTrail outside of Rails, so I still think it's worthy to address this issue.

[cout]

Yes, in the case where I'm getting the failure, paper trail is being used
outside rails. In particular, it's failing in the tests we wrote for a
rails app. The test requires the model files and then sets up a connection
to the database. This is generally okay with activerecord, since as you
pointed out, relationships are lazily evaluated.

On Tue, Oct 30, 2012 at 3:04 PM, Ben Atkins notifications@github.comwrote:

@cout https://github.com/cout - Just out of curiosity, in the scenario
where you encountered this, were you attempting to use PaperTrail outside
of Rails? I only ask because it seems to me that the has_many relationship
is lazily-evaluated, in the sense that the module that defines the
has_paper_trail method gets included into ActiveRecord with via
ActiveSupport's on_load hook methodhttps://github.com/airblade/paper_trail/blob/master/lib/paper_trail.rb#L91
.

As far as I can tell, that gets called after ActiveRecord has instantiated
a connection to the database in the rails boot cycle, so it would not be
encountered if using PaperTrail in Rails as the documentation outlines.
That being said, we are exploring the possibility of supporting usage of
PaperTrail outside of Railshttps://github.com//issues/119,
so I still think it's worthy to address this issue.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/177#issuecomment-9918774.