Custom initializer breaks PaperTrail 3.0.3 (rails 3.2)

[flockom]

3.0.3 seems to be breaking when calling has_paper_trail in a model.
3.0.2 works fine.
top of the stack:

undefined method `timestamp_sort_order' for #<Class:0x007fd1d02fad60>
activerecord (3.2.18) lib/active_record/dynamic_matchers.rb:55:in `method_missing'
paper_trail (3.0.3) lib/paper_trail/has_paper_trail.rb:70:in `has_paper_trail'

[batter]

Can you provide more information about what is causing this (method calls, scenario, etc.)? Ideally a dummy app would be super helpful. I just setup a very bare-bones dummy app with Rails 3.2.18 and PaperTrail 3.0.3, with a basic widget and it seemed like it was working fine, so I'm wondering how to reproduce this.

Also, what happens when you invoke ModelName.paper_trail_version_class (it should return PaperTrail::Version unless you are using a custom version class) and PaperTrail::Version.timestamp_sort_order (it should return a collection of Arel::Nodes)?

[flockom]

I have reproduced the issue here:
https://github.com/flockom/paper_trail_test

I think it has to do with https://github.com/flockom/paper_trail_test/blob/master/config/initializers/paper_trail.rb
which I got from https://github.com/airblade/paper_trail#storing-metadata

1.9.3-p484 :001 > HighScore.paper_trail_version_class
NoMethodError: undefined method `timestamp_sort_order' for #<Class:0x007fc0cc3ad1c8>

[batter]

It would appear as though you are correct. Without an initializer it seems to work great, with one it chokes. I'm guessing this has to do with loading in the model via a Rails::Engine.

Hmm, after a little more testing this seems to be an issue with Rails 4 as well. This is something I didn't catch in my testing and something I wasn't anticipating. It also doesn't appear to show up in the dummy app we use for testing (which does have an initializer attached to it), which is odd. I was under the impression that loading the model in via a Rails::Engine was supposed to solve a lot of potential issues (see #347), but I may need to do some more research into this. Thanks for the bug report, I'll see what I can do. I guess for now, you should use 3.0.2.

[batter]

So one workaround that you can use for now is placing this line in your custom initializer, like so:

# config/initializers/paper_trail.rb
module PaperTrail
  class Version < ActiveRecord::Base
    include PaperTrail::VersionConcern
  end
end

But, it seems as though then the model doesn't end up getting loaded in through the Rails::Engine, which defeats the whole purpose of the feature, so I need to do more research to figure out what we can do to work around that.

Another workaround is to manually require the version class from your initializer. Again, I believe this circumvents the benefits that come from loading the model in through a Rails::Engine to begin with, but it is another way to do it:

# config/initializers/paper_trail.rb
require 'paper_trail/frameworks/active_record/models/paper_trail/version'

module PaperTrail
  class Version < ActiveRecord::Base
  end
end

[batter]

After doing a little more experimentation, it appears as though this may be the correct way to make it work properly. You want to change your initializer so that the model has already been eager loaded by the engine by the time this code gets executed, by calling eager_load! on the engine, like so:

# config/initializers /paper_trail.rb
PaperTrail::Rails::Engine.eager_load!

module PaperTrail
  class Version < ActiveRecord::Base
    # custom code goes here
  end
end

Looks like I will need to update the README accordingly. Glad I was able to find the proper method for getting this to work. I'll keep this open until I can update the README appropriately.

[batter]

Ok I updated the README, hopefully that is clear enough. Do you think that's confusing? Any feedback on how to make this as clear as possible would be appreciated.

[flockom]

Easy enough. Thanks for the quick response.