Running in development, the following error is not encountered.
Having added a new attribute to a model, upon deploying to staging server, the model's pages are generating
ActionView::Template::Error (undefined method `[...]' for #<Optionrate:)x)))...
and it references an attribute that is present in the current schema.rb file and happens to be listed within attr_accessible. The error is raised both in the _form call to attribute and in views where the attribute, being a boolean, is invoked via an if clause, such as:
<% if @optionrate.auto_price %>
I can even the new attribute via the console
Optionrate.all.each { |n| n.update_attribute(:auto_price, true)}
Having a number of booleans with the same prefix, or possibly two underscores in the attribute's name, I changed the name, re-ran everything and got the same behaviour!
Having updated two models, the other model generates the same undefined method error. Thus the error clearly is occurring because of the structural changes.
The steps followed for the migration was:
pg_dump the existing DB
rake db:migrate VERSION=0
deploy changes
rake db:migrate
psql load existing data
** update **
it turns out there is a difference in environments. First I was on a garden path; needed to invoke the console of the production environment
RAILS_ENV=production bundle exec rails c
Then in fact, those attributes were not present in console queries.
Cannot fathom why it is working in development and not in production mode.
If someone hits this issue...
The console rake commands are not necessarily aware of the environment to execute upon. Thus, I was actually not modifying the production data (being a big file, I was not reading through all the postgresql messages...
pg_dump the existing DB
RAILS_ENV=production bundle exec rake db:migrate VERSION=0
deploy changes
RAILS_ENV=production bundle exec rake db:migrate
psql load existing data
Specify the environment...