New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrations fail in rails 3.2.9 #17

Closed
EnriqueVidal opened this Issue Nov 26, 2012 · 10 comments

Comments

Projects
None yet
3 participants
@EnriqueVidal
Copy link

EnriqueVidal commented Nov 26, 2012

I'm just installed apartment in our appliaction, I followed the steps in your readme:

# config/initializers/apartment.rb

##
# Apartment Configuration
Apartment.configure do |config|

  # these models will not be multi-tenanted,
  # but remain in the global (public) namespace
  config.excluded_models = %w{
    ActiveRecord::SessionStore::Session
    Account
  }

  # use postgres schemas?
  config.use_postgres_schemas = true

  # configure persistent schemas (E.g. hstore )
  # config.persistent_schemas = %w{ hstore }

  # add the Rails environment to database names?
  # config.prepend_environment = true
  # config.append_environment = true

  # supply list of database names
  config.database_names = lambda{ Account.pluck :subdomain }
end

I added config.middleware.use 'Apartment::Elevators::Subdomain' to config/application.rb

However after creating a demo account (tenant) and running rake apartment:migrate I get the following message:

Migrating demo database
rake aborted!
PG::Error: ERROR:  no schema has been selected to create in
: CREATE TABLE "schema_migrations" ("version" character varying(255) NOT NULL) 
Tasks: TOP => apartment:migrate

Am I missing anything besides this? Here's a the full stack trace of the migrate task:

** Invoke apartment:migrate (first_time)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
** Invoke db:_dump (first_time)
** Execute db:_dump
** Invoke db:schema:dump (first_time)
** Invoke environment 
** Invoke db:load_config 
** Execute db:schema:dump
** Execute apartment:migrate
Migrating demo database
rake aborted!
PG::Error: ERROR:  no schema has been selected to create in
: CREATE TABLE "schema_migrations" ("version" character varying(255) NOT NULL) 
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/connection_adapters/postgresql_adapter.rb:652:in `async_exec'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/connection_adapters/postgresql_adapter.rb:652:in `block in execute'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/connection_adapters/abstract_adapter.rb:280:in `block in log'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activesupport-3.2.9/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/connection_adapters/abstract_adapter.rb:275:in `log'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/connection_adapters/postgresql_adapter.rb:651:in `execute'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/connection_adapters/abstract/schema_statements.rb:170:in `create_table'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/connection_adapters/abstract/schema_statements.rb:426:in `initialize_schema_migrations_table'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/migration.rb:663:in `initialize'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/migration.rb:570:in `new'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/migration.rb:570:in `up'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/activerecord-3.2.9/lib/active_record/migration.rb:551:in `migrate'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/apartment-0.17.3/lib/apartment/migrator.rb:10:in `block in migrate'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/apartment-0.17.3/lib/apartment/adapters/abstract_adapter.rb:63:in `process'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/apartment-0.17.3/lib/apartment/database.rb:11:in `process'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/apartment-0.17.3/lib/apartment/migrator.rb:9:in `migrate'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/apartment-0.17.3/lib/tasks/apartment.rake:8:in `block (3 levels) in <top (required)>'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/apartment-0.17.3/lib/tasks/apartment.rake:6:in `each'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/apartment-0.17.3/lib/tasks/apartment.rake:6:in `block (2 levels) in <top (required)>'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/task.rb:227:in `call'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/task.rb:227:in `block in execute'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/task.rb:222:in `each'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/task.rb:222:in `execute'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/task.rb:166:in `block in invoke_with_call_chain'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/task.rb:159:in `invoke_with_call_chain'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/task.rb:152:in `invoke'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:140:in `invoke_task'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:98:in `block (2 levels) in top_level'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:98:in `each'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:98:in `block in top_level'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:107:in `run_with_threads'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:92:in `top_level'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:70:in `block in run'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:157:in `standard_exception_handling'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/lib/rake/application.rb:67:in `run'
/Users/enrique/.rbenv/versions/1.9.3-p286/lib/ruby/gems/1.9.1/gems/rake-10.0.0/bin/rake:37:in `<top (required)>'
/Users/enrique/.rbenv/versions/1.9.3-p286/bin/rake:23:in `load'
/Users/enrique/.rbenv/versions/1.9.3-p286/bin/rake:23:in `<main>'
Tasks: TOP => apartment:migrate
@bradrobertson

This comment has been minimized.

Copy link
Contributor

bradrobertson commented Nov 26, 2012

I wasn't able to replicate this on a Vanilla Rails 3.2.9 app.

Check out my source and see if you're doing anything different. This is with postgresql 9.1

@EnriqueVidal

This comment has been minimized.

Copy link
Author

EnriqueVidal commented Nov 26, 2012

Both of our examples look the same, however I'm running postgresql 9.2 although I don't think that should make it fail, any advice? btw I only looked at your initializer, do I need to look at any other file?

@EnriqueVidal

This comment has been minimized.

Copy link
Author

EnriqueVidal commented Nov 27, 2012

I rolled back to postgresql 9.1.5 and ran this rake task again, I got a different message this time:

rake apartment:migrate
Migrating demo database
rake aborted!
undefined local variable or method `new_search_path' for #<Apartment::Adapters::PostgresqlSchemaAdapter:0x007ffce666fa18>
Tasks: TOP => apartment:migrate

What could I be missing?

@bradrobertson

This comment has been minimized.

Copy link
Contributor

bradrobertson commented Nov 27, 2012

that's actually a bug which I've fixed in Dev. I'll release a new version today. The issue though is that it's searching for a schema that doesn't exist. Is there an account in your system that's returning a db name that doesn't actually exist?

I'll let you know when the new version is out.

B

On 2012-11-27, at 1:44 AM, Enrique Vidal wrote:

I rolled back to postgresql 9.1.5 and ran this rake task again, I got a different message this time:

rake apartment:migrate
Migrating demo database
rake aborted!
undefined local variable or method `new_search_path' for #Apartment::Adapters::PostgresqlSchemaAdapter:0x007ffce666fa18
Tasks: TOP => apartment:migrate
What could I be missing?


Reply to this email directly or view it on GitHub.

@EnriqueVidal

This comment has been minimized.

Copy link
Author

EnriqueVidal commented Nov 27, 2012

demo is a newly created Account so the db doesn't exists yet, I forgot to add Apartment::Database.create subdomain on my Account model on an after_create callback, will try it again. Do you plan to add support for postgres 9.2?

@EnriqueVidal

This comment has been minimized.

Copy link
Author

EnriqueVidal commented Nov 27, 2012

I have another question, now that I am creating a schema from the model each time, I opened the db console, and did this:

test_app_development=> SET search_path = demo;
SET
test_app_development=> \dt
                List of relations
 Schema |        Name         | Type  |  Owner   
--------+---------------------+-------+----------
 demo   | accounts            | table | invoices
 demo   | audits              | table | invoices
 demo   | enrollments         | table | invoices
 demo   | fiscal_infos        | table | invoices
 demo   | invoices            | table | invoices
 demo   | line_items          | table | invoices
 demo   | oauth_access_grants | table | invoices
 demo   | oauth_access_tokens | table | invoices
 demo   | oauth_applications  | table | invoices
 demo   | payments            | table | invoices
 demo   | roles               | table | invoices
 demo   | schema_migrations   | table | invoices
 demo   | users               | table | invoices
(13 rows)

Why is accounts in my demo schema if we're ignoring this model?

@nivanson

This comment has been minimized.

Copy link

nivanson commented Nov 27, 2012

All databases have the same schemas. It is the query that is modified to ignore the model and fall back to the public database. See issue #14:

27 nov 2012 kl. 19:54 skrev Enrique Vidal notifications@github.com:

I have another question, now that I am creating a schema from the model each time, I opened the db console, and did this:

test_app_development=> SET search_path = demo;
SET
test_app_development=> \dt
List of relations
Schema | Name | Type | Owner
--------+---------------------+-------+----------
demo | accounts | table | invoices
demo | audits | table | invoices
demo | enrollments | table | invoices
demo | fiscal_infos | table | invoices
demo | invoices | table | invoices
demo | line_items | table | invoices
demo | oauth_access_grants | table | invoices
demo | oauth_access_tokens | table | invoices
demo | oauth_applications | table | invoices
demo | payments | table | invoices
demo | roles | table | invoices
demo | schema_migrations | table | invoices
demo | users | table | invoices
(13 rows)
Why is accounts in my demo schema if we're ignoring this model?


Reply to this email directly or view it on GitHub.

@bradrobertson

This comment has been minimized.

Copy link
Contributor

bradrobertson commented Nov 28, 2012

I've pushed out the new gem so you won't get that invalid exception anymore when it can't find a schema. As @nivanson mentioned, all tables are currently stored in all schemas, we're working to fix that going forward but for now it shouldn't cause you any problems, it's just more of an annoyance than anything.

Everything resolved?

@EnriqueVidal

This comment has been minimized.

Copy link
Author

EnriqueVidal commented Nov 28, 2012

Yeah it really looks that way, thanks a lot for taking the time to walk me through this, I just have one possibly unrelated question, do I need to keep my session store in ActiveRecord? or can I use cookies?

You may close this issue, thanks again for your great support.

@bradrobertson

This comment has been minimized.

Copy link
Contributor

bradrobertson commented Nov 28, 2012

No we actually use cookies it's just there as an example.
On Nov 28, 2012 12:49 AM, "Enrique Vidal" notifications@github.com wrote:

Yeah it really looks that way, thanks a lot for taking the time to walk me
through this, I just have one possibly unrelated question, do I need to
keep my session store in ActiveRecord? or can I use cookies?

You may close this issue, thanks again for your great support.


Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-10791599.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment