Generator fails for STI models

[zeisler]

Generator fails for STI models

[zeisler]

I looked a this a little and was not able to come up with a solution. I would like mocks generation to soft fail and continue with the rests of the mocks so any issue like this would not be a blockers. Your welcome to take a look and see if you can find a solution. My guess is that the parent model is not loaded with child model making it so the active record methods are not there and this case is being masked in some way.

[joshleitzel]

Yeah, the issue seems to be the ModelReader method that evals the file, which is logging this error:

Error loading Model: child
  `uninitialized constant #<Module:0x00000101307b20>::Parent`

Not sure how to go about solving this, but I imagine this will be a problem for apps that have model sub-classes of any kind.

What about rescuing the uninitialized constant error and then trying to look up that constant in the model directory? Would that be a good approach?

[zeisler]

Your suggestion as sounds good to me, your welcome to have a go at it, otherwise I won't be able to work on for a couple of days.

[joshleitzel]

Cool, I'll take a stab at it!

[zeisler]

I just did a spike on this and it seem Rails is some how loading the parent class. Originally ActiveMocker would dynamically create mocks for units tests, but I optimized it with a static ruby file. So Rails could not be loaded, but now there is no reason it couldn't be loaded for the generation of the mocks. The only thing is that it would take a little refactoring to swap out the APIs. It could also be a little slower, but I don't think by much, also the complexity would be reduced. Also there are future benefits of having more advanced association if it does hook to ActiveRecord. If there is a simple fix lets just keep it the same, but if not the refactor will need to be done.

[zeisler]

I have test version on this branch to try out model_reader_to_ar. All High level tests are passing but many unit tests are still failing. In some cases of more complex associations foreign keys and classes are now correct because it is connected to active record.

[joshleitzel]

Hmm, I think I'm confused. Rails is loaded inside the Rake task, isn't it?

I think the error I reported before, uninitialized constant #<Module:0x00000101307b20>::Parent, might have been in the context of RSpec instead of the Rake task. In RSpec, the example app is not actually loaded, so Parent is unknown. Note the differences between running the Rake task and running RSpec:

Scenario (1): when running rake active_mocker:build

# after parsing app/models/account.rb
    35:       Logger.error "ActiveMocker :: Error loading Model: #{model_name} \n \t\t\t\t\t\t\t\t`#{e}` \n"
    36:       Logger.error "\t\t\t\t\t\t\t\t #{file_path}\n"
    37:       failure = true
    38:     end
    39:   klass = failure ? 'failure' : m.const_get(m.constants.first)
 => 40:   binding.pry
    41:   return klass unless failure
    42:   return false
    43: end

[1] pry(#<ActiveMocker::ModelReader>)> klass
=> #<Module:0x00000101c862f0>::Account
[2] pry(#<ActiveMocker::ModelReader>)> klass.respond_to? :get_named_scopes
=> true
[3] pry(#<ActiveMocker::ModelReader>)> klass.ancestors
=> [#<Module:0x00000101c862f0>::Account,
 ActiveMocker::ActiveRecord::Base,
 Object,
 ActiveSupport::Dependencies::Loadable,
 PP::ObjectMixin,
 JSON::Ext::Generator::GeneratorMethods::Object,
 Kernel,
 BasicObject]
[4] pry(#<ActiveMocker::ModelReader>)> Rails
=> Rails

# after parsing app/models/child.rb

[1] pry(#<ActiveMocker::ModelReader>)> klass
=> #<Module:0x0000010133ce10>::Child (call '#<Module:0x0000010133ce10>::Child.connection' to establish a connection)
[2] pry(#<ActiveMocker::ModelReader>)> klass.respond_to? :get_named_scopes
=> false
[3] pry(#<ActiveMocker::ModelReader>)> klass.ancestors
=> [#<Module:0x0000010133ce10>::Child (call '#<Module:0x0000010133ce10>::Child.connection' to establish a connection),
 #<Module:0x00000103cb3528>,
 Parent (call 'Parent.connection' to establish a connection),
 #<Module:0x000001013472e8>,
 ActiveRecord::Base,
 ActiveRecord::Store,
 ActiveRecord::Serialization,
 ActiveModel::Serializers::Xml,
...

Scenario (2): when running rspec spec/lib/active_mocker/model_reader/generate_spec.rb:23

# after parsing app/models/account.rb
[1] pry(#<ActiveMocker::ModelReader>)> klass
=> #<Module:0x00000101dff118>::Account
[2] pry(#<ActiveMocker::ModelReader>)> klass.respond_to? :get_named_scopes
=> true
[3] pry(#<ActiveMocker::ModelReader>)> klass.ancestors
=> [#<Module:0x00000101dff118>::Account, ActiveMocker::ActiveRecord::Base, Object, PP::ObjectMixin, JSON::Ext::Generator::GeneratorMethods::Object, Kernel, BasicObject]
[4] pry(#<ActiveMocker::ModelReader>)> Rails
NameError: uninitialized constant ActiveMocker::ModelReader::Rails
from (pry):4:in `eval_file'

# after parsing app/models/child.rb

[1] pry(#<ActiveMocker::ModelReader>)> klass
=> "failure"

So in scenario 1 (the behavior users of the gem actually see), the problem is not that the parent class can't be loaded, it's that it is loaded and therefore the real ActiveRecord::Base is used, not ActiveMocker::ActiveRecord::Base. In scenario 2 (the gem's test suite), it causes a failure because of the uninitialized constant error.

[zeisler]

I found the same thing to be true. I wonder if there is a way to stop rails from auto-loading the parent class. Stepping through the debugger it just jumps right to the parent class.

[joshleitzel]

You mean stop Child from loading Parent, or stop Parent from loading ActiveRecord::Base?

[zeisler]

I mean to stop rails from auto-loading classes in that instance. So scenario 1 would be the same as scenario 2, but yes ultimately stoping the parent from loading would cause an uninitialized constant error and keep ActiveRecord::Base from loading.

[joshleitzel]

Well then the problem becomes that the mock for Child will be incomplete when there are things defined on Parent that Child should be inheriting. Also think about things like concerns. If Child includes a concern, that concern might define associations, validations, etc that the Child mock should know about.

[zeisler]

Yes your are right, I just mean that the parent must be loaded manually so
it can be sandboxed with in ActiveMocker::ActiveRecord::Base. Sorry if I
am being confusing.

On Mon, Aug 11, 2014 at 12:12 PM, Josh Leitzel [email protected]
wrote:

Well then the problem becomes that the mock for Child will be incomplete
when there are things defined on Parent that Child should be inheriting.
Also think about things like concerns. If Child includes a concern, that
concern might define associations, validations, etc that the Child mock
should know about.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[zeisler]

I pushed up warning that single table inheritance is not supported yet. This should allow the mock generation to continue by skipping that model for now.

084ff52

[zeisler]

Test this out with your project. 08e266f. If there are no problems found I'll push out a new version at the end of the week.

[zeisler]

Version 1.6.3 should resolve this issue.

[joshleitzel]

Thanks for your help with this. Your new version does silence the STI problems by printing debug messages, but the generator's now running into a problem with my omniauth-identity model:

Errno::ENOENT: No such file or directory @ rb_sysopen - ~/rails_app/app/models/omni_auth/identity/models/active_record.rb
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/file_reader.rb:6:in `initialize'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/file_reader.rb:6:in `open'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/file_reader.rb:6:in `read'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_reader.rb:74:in `read_file'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_reader.rb:37:in `load_parent_class'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_reader.rb:30:in `sandbox_model'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_reader.rb:22:in `klass'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_reader.rb:16:in `parse'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_schema/generate.rb:168:in `get_model'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_schema/generate.rb:38:in `block in run'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_schema/generate.rb:36:in `map'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/model_schema/generate.rb:36:in `run'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/generate.rb:43:in `generate_model_schema'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/generate.rb:66:in `create_template'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/generate.rb:23:in `initialize'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/task.rake:5:in `new'
~/.rvm/gems/ruby-2.1.0@gemset/gems/active_mocker-1.6.3/lib/active_mocker/task.rake:5:in `block (2 levels) in <top (required)>'

The model looks like this:

class Identity < OmniAuth::Identity::Models::ActiveRecord; end

Unfortunately since the gem isn't able to process models that don't directly inherit from ActiveRecord::Base, I won't be able to use it. All of my models inherit from either ApplicationModel, an STI class, or—as here—a different class like OmniAuth::Identity::Models::ActiveRecord.

Thanks for the help though! 😃 Hopefully a future version will support less straightforward class hierarchies like mine.

[zeisler]

I was unaware of that being a use case. With the changes I have made that should not be a very difficult fix.

[zeisler]

Does your ApplicationModelultimately inherit form ActiveRecord?

[joshleitzel]

Yep!

[zeisler]

Closing this and open a new issue for the non standard base class.