This project is archived and is in readonly mode.

#5583 ✓stale
Sean

problem with migrations/schema loading when using STI

Reported by Sean | September 8th, 2010 @ 04:50 PM

I ran into a problem when deploying a Rails3 app on a new server. I have a couple of STI models, and when running db:migrate or schema:load, AR would attempt to parse the associations in the STI models, based on tables that it hadn't yet created, and would fail. (I didn't notice it in development as the STI models were created after the table which they inherited from already existed.)

For example, I would get the following error, generated from an STI model:

# rake db:schema:load RAILS_ENV=production
PGError: ERROR:  relation "offers" does not exist
LINE 4:              WHERE a.attrelid = '"offers"'::regclass
                                        ^
:             SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull
              FROM pg_attribute a LEFT JOIN pg_attrdef d
                ON a.attrelid = d.adrelid AND a.attnum = d.adnum
             WHERE a.attrelid = '"offers"'::regclass
               AND a.attnum > 0 AND NOT a.attisdropped
             ORDER BY a.attnum
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/connection_adapters/abstract_adapter.rb:202:in `rescue in log'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/connection_adapters/abstract_adapter.rb:194:in `log'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/connection_adapters/postgresql_adapter.rb:483:in `query'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/connection_adapters/postgresql_adapter.rb:1015:in `column_definitions'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/connection_adapters/postgresql_adapter.rb:662:in `columns'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/base.rb:679:in `columns'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/base.rb:687:in `columns_hash'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/base.rb:780:in `descends_from_active_record?'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/base.rb:786:in `finder_needs_type_condition?'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/base.rb:897:in `relation'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/named_scope.rb:32:in `scoped'
/usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.0/lib/active_record/base.rb:441:in `where'
/data/app/works/app/models/work_offer.rb:5:in `<class:WorkOffer>'

Following is my work_offer.rb, AR was choking on the SQL being stored in a class variable:

class WorkOffer < Offer

  has_one :country, :through => :work

  default_scope where("work_id is not null and user_id is null")

  cattr_reader :joiners
  @@joiners = 'INNER JOIN "works" ON "works"."id" = "offers"."work_id" 
    left outer join "countries" on "works"."country_id" IS NOT NULL
    inner join "areas" on ("works"."country_id" = "countries"."id" 
    and "countries"."area_id" = "areas"."id")'
    # used for scopes because the activerecord joins doesn't do it

end

The workaround was to temporarily move the STI models out of my app/models folder, run db:schema:load, and then move them back.

Since STI models don't have their own schema, it seems that they should be skipped over when loading the schema?

Comments and changes to this ticket

  • Santiago Pastorino

    Santiago Pastorino February 9th, 2011 @ 12:31 AM

    • State changed from “new” to “open”
    • Tag changed from activerecord rails3, schema migrations, db:schema:load, rails3.0.0 to activerecord rails3, schema migrations, dbschemaload, rails300

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • Santiago Pastorino

    Santiago Pastorino February 9th, 2011 @ 12:31 AM

    • State changed from “open” to “stale”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Pages