"missing attribute: state" when state attribute is not included in the query

Question

"missing attribute: state" when state attribute is not included in the query

davout opened this issue 12 years ago · 29 comments

davout commented 12 years ago

When selecting aggregates with custom SQL the error is raised.
It worked perfectly in 0.1.4 but broke in 0.1.5

Answer 1 · 2013-02-12T11:32:56.000Z

Can you give me an example model and corresponding query to reproduce this?

Answer 2 · 2013-02-12T11:41:16.000Z

http://pastie.org/private/n3r0focjcdges7durjog
The state machine is defined at line 85, the failing method at 160.

Answer 3 · 2013-02-12T12:09:33.000Z

It fails here.

transitions (0.1.5) lib/active_model/transitions.rb:66:in `set_initial_state'
activesupport (3.2.12) lib/active_support/callbacks.rb:405:in `_run__3282874665777803106__initialize__1090282513155503724__callbacks'
activesupport (3.2.12) lib/active_support/callbacks.rb:405:in `__run_callback'
activesupport (3.2.12) lib/active_support/callbacks.rb:385:in `_run_initialize_callbacks'
activesupport (3.2.12) lib/active_support/callbacks.rb:81:in `run_callbacks'
activerecord (3.2.12) lib/active_record/base.rb:523:in `init_with'
activerecord (3.2.12) lib/active_record/inheritance.rb:68:in `instantiate'
activerecord (3.2.12) lib/active_record/querying.rb:38:in `block (2 levels) in find_by_sql'
activerecord (3.2.12) lib/active_record/querying.rb:38:in `collect!'
activerecord (3.2.12) lib/active_record/querying.rb:38:in `block in find_by_sql'
activerecord (3.2.12) lib/active_record/explain.rb:40:in `logging_query_plan'
activerecord (3.2.12) lib/active_record/querying.rb:37:in `find_by_sql'
newrelic_rpm (3.5.6.46) lib/new_relic/agent/method_tracer.rb:491:in `block in find_by_sql_with_trace_ActiveRecord_self_name_find_by_sql'
newrelic_rpm (3.5.6.46) lib/new_relic/agent/method_tracer.rb:240:in `trace_execution_scoped'
newrelic_rpm (3.5.6.46) lib/new_relic/agent/method_tracer.rb:486:in `find_by_sql_with_trace_ActiveRecord_self_name_find_by_sql'
activerecord (3.2.12) lib/active_record/relation.rb:171:in `exec_queries'
activerecord (3.2.12) lib/active_record/relation.rb:160:in `block in to_a'
activerecord (3.2.12) lib/active_record/explain.rb:40:in `logging_query_plan'
activerecord (3.2.12) lib/active_record/relation.rb:159:in `to_a'
activerecord (3.2.12) lib/active_record/relation/finder_methods.rb:159:in `all'
app/models/trade_order.rb:161:in `get_orders'

Answer 4 · 2013-02-13T14:03:47.000Z

Thanks for the report, I'll look into this as soon as I can.

Answer 5 · 2013-02-19T15:11:06.000Z

This was broken in bf5d2b6 by adding Mongoid support. Using respond_to? does not work as the state and state= methods still exist even when the attribute was not loaded. I would fix it, but I don’t know how to do that without breaking Mongoid support.

We now just use 0.1.4.

Answer 6 · 2013-02-28T23:21:45.000Z

I just reverted: #68
and released 0.1.6.
Please let me know if that works for you guys.

Answer 7 · 2013-03-01T10:16:53.000Z

Hey, thanks a lot, looks like it's working.
Except now my tests are throwing

WARNING: Transitions::Machine#new_update or Transitions::Machine#new_initialize already defined. This can possibly break ActiveModel::Transitions

multiple times.

Answer 8 · 2013-03-01T11:17:04.000Z

Not sure why you get that but this was added in a recent pull request:

https://github.com/troessner/transitions/pull/73/files#L1R47

The same here for me:

WARNING: Transitions::Machine#new_update or Transitions::Machine#new_initialize already defined. This can possibly break ActiveModel::Transitions.
WARNING: Transitions::Machine#new_update or Transitions::Machine#new_initialize already defined. This can possibly break ActiveModel::Transitions.
...................................................................................................................*.....................................................................................................

I have a more or less vanilla rails app - seems like this happens because more than one model use transitions, but that is just a shot in the blue from my side.

@cmw do you see what's going wrong here?

Answer 9 · 2013-03-01T11:18:10.000Z

@troessner yeah, a bunch of my models include AM::T

Answer 10 · 2013-03-03T12:19:00.000Z

I get a nice SystemStackError with 0.1.6:

/usr/local/lib/ruby/gems/1.8/gems/transitions-0.1.6/lib/active_model/transitions.rb:36:in `old_initialize': stack level too deep (SystemStackError)
        from /usr/local/lib/ruby/gems/1.8/gems/transitions-0.1.6/lib/active_model/transitions.rb:36:in `initialize'
        from /usr/local/lib/ruby/gems/1.8/gems/transitions-0.1.6/lib/transitions.rb:45:in `new'
        from /usr/local/lib/ruby/gems/1.8/gems/transitions-0.1.6/lib/transitions.rb:45:in `state_machine'
        from /vagrant/rails_app/app/models/news_feed.rb:15

Answer 11 · 2013-03-03T23:03:20.000Z

@maser interesting. So I guess you'll stick with 0.1.4 for now, right?
Can you provide me with a test case on how to reproduce that behaviour?

Besides that, it seems like this error was introduced with: #73

@cmw any ideas on that?

Answer 12 · 2013-03-04T22:06:45.000Z

@maser can you do me a favor and narrow it down for me a litte?

This means:

Clone this repo
Adjust your Gemfile to use your local instead of the installed one
Check out commit

commit b2e64fe
Merge: ab8e1bb 98dc77d
Author: Timo Rößner timo.roessner@googlemail.com
Date: Thu Jan 31 03:08:15 2013 -0800

and check if it's working again.

Then check out

commit 1304a15
Author: Christian M. Weis christian.weis@gmail.com
Date: Fri Feb 1 19:06:03 2013 +0100
Support for configurable column names

and see if it fails.

Answer 13 · 2013-03-04T23:34:27.000Z

@troessner Yes, we are using 0.1.4 for now. b2e64fe and 1304a15 work as you expected them to, so your fix works. Thanks!

There is a new arning, though: lib/transitions/version.rb:2: warning: already initialized constant VERSION.

Answer 14 · 2013-03-05T00:25:27.000Z

Wait, what? Now I am confused - from your error report I thought that 1304a15 introduced a bug which you were experiencing now. So I was expecting that b2e64fe works for you but 1304a15 not. So both those commits work for you?

Answer 15 · 2013-03-05T00:27:21.000Z

Also from what you said I am not sure if this still affects the current version. Does

so your fix works.

mean that it works for you now with v 0.1.6? If not, can you tell me how to reproduce this error? Because I'm using 0.1.6 in multiple rails apps and have no problems so far.

Answer 16 · 2013-03-05T00:32:58.000Z

@troessner Sorry, I wasn’t clear enough. b2e64fe works, 1304a15 does not, neither does 0.1.6.

I can try to reproduce the error in a clean app tomorrow.

Answer 17 · 2013-03-05T00:52:21.000Z

b2e64fe works, 1304a15 does not, neither does 0.1.6.

Ah, good to know.

I can try to reproduce the error in a clean app tomorrow.

That would be very helpful, thanks!

Answer 18 · 2013-03-05T09:13:31.000Z

I cannot reproduce the problem in a new Rails application. I’ll have to test if there is an incompatibility with some other part of the application (it is large enough for that to take some time though).

Answer 19 · 2013-03-05T10:00:08.000Z

The warning

WARNING: Transitions::Machine#new_update or Transitions::Machine#new_initialize already defined. This can possibly break ActiveModel::Transitions

just means that AM::T got loaded more than once and the condition prevented the aliasing block from producing endless loops.

I only included the warning because it's conceivable, that Transitions::Machine#new_initialize could be defined before the module is added. This will potentially break something, so, if things don't seem to work right, this is a pointer to where the problem might be.

Answer 20 · 2013-03-05T10:42:30.000Z

@cmw I get the warning multiple times each time Rails is loaded.

I have multiple models with state machines, all the models include ìnclude ActiveModel::Transitions`.
Tried

ActiveSupport.on_load(:active_record) do
  ActiveRecord::Base.send(:extend, ActiveModel::Transitions)
end

as a workaround, but apparently that fails too because the columns are not yet defined on the model at that point and AM::T tries to find the state column.

Trying to extend AR later in the lifecycle doesn't work either as the state_machine call fails inside the model rightfully complaining that the method is undefined.

Answer 21 · 2013-03-05T10:49:49.000Z

@cmw I see your point, however this warning can get annoying pretty quick - how about removing this warning and use some method name we're sure nobody else uses, like new_transitions_initialize?

Answer 22 · 2013-03-05T10:51:31.000Z

@troessner would that solve the warning popping when AM::T is included multiple times in different models ?

Answer 23 · 2013-03-05T10:58:33.000Z

We wouldn't necessarily have to display the warning in that case (though we still need the check to protect from endless loop). Not a bad idea, though of course we can't really know that nobody uses a method with that name.

Answer 24 · 2013-03-05T12:11:38.000Z

@troessner would that solve the warning popping when AM::T is included multiple times in different models ?

Yes.

We wouldn't necessarily have to display the warning in that case (though we still need the check to protect from endless loop).

Yeah, then let's drop it.

Not a bad idea, though of course we can't really know that nobody uses a method with that name.

True, but I'd say the chances are so low that we should go with it ..:)

Do you have the time to whip up a pull request? I can do it as well but unfortunately I'm pretty loaded for the next few days.

Answer 25 · 2013-03-06T16:53:11.000Z

@troessner You got it :)

Answer 26 · 2013-03-07T10:00:35.000Z

Alright, I just released 1.0.7 with all the latest and greatest..;)

@davout the warnings should be gone now
@maser please let me know if you have still that SystemStackError with that version or if this problem in general just has gone away - and if so, please open up a dedicated issue.

-> Closing this.

Answer 27 · 2013-03-07T10:49:02.000Z

Works perfect. Thanks a lot!

Answer 28 · 2013-03-07T22:58:35.000Z

@troessner I still get it, but I won’t open an issue before I know how to reproduce this.

Answer 29 · 2013-07-19T22:21:55.000Z

Not sure if I should open a new issue, but I'm getting this again.

ruby 2.0.0
rails 4.0.0 + postgres 9.2
transitions (0.1.9 f8a0b94)

2.0.0 (main):0 > a = Auction.select('id').last
  Auction Load (0.6ms)  SELECT id FROM "auctions" ORDER BY auctions.ends_at DESC LIMIT 1
ActiveModel::MissingAttributeError: missing attribute: state
from /Users/Ian/.rvm/gems/ruby-2.0.0-p195/bundler/gems/rails-c119faa86458/activerecord/lib/active_record/attribute_methods/read.rb:89:in `block (2 levels) in read_attribute'