Permalink
Browse files

Use 'public' schema path when connecting to 'postgres' database. [#170

…state:resolved]

Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
  • Loading branch information...
tarmo authored and lifo committed May 13, 2008
1 parent f498f22 commit 3fee2378edd45188e41a7d14d4ca0a88280b541e
Showing with 2 additions and 2 deletions.
  1. +2 −2 railties/lib/tasks/databases.rake
@@ -45,7 +45,7 @@ namespace :db do
when 'postgresql'
@encoding = config[:encoding] || ENV['CHARSET'] || 'utf8'
begin
- ActiveRecord::Base.establish_connection(config.merge('database' => 'postgres'))
+ ActiveRecord::Base.establish_connection(config.merge('database' => 'postgres', 'schema_search_path' => 'public'))
ActiveRecord::Base.connection.create_database(config['database'], config.merge('encoding' => @encoding))
ActiveRecord::Base.establish_connection(config)
rescue
@@ -368,7 +368,7 @@ def drop_database(config)
when /^sqlite/
FileUtils.rm(File.join(RAILS_ROOT, config['database']))
when 'postgresql'
- ActiveRecord::Base.establish_connection(config.merge('database' => 'postgres'))
+ ActiveRecord::Base.establish_connection(config.merge('database' => 'postgres', 'schema_search_path' => 'public'))
ActiveRecord::Base.connection.drop_database config['database']
end
end

10 comments on commit 3fee237

@blakeeb

This comment has been minimized.

Show comment
Hide comment
@blakeeb

blakeeb Nov 5, 2011

I'm trying to connect to a postgres schema other than "public" within my test environment, but it seems ActiveRecord is overwriting the schema_search_path to "public" due to this commit - inconvenient. I have a very complex postgres database which requires schemas for adequate testing.

Link to original bug: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/170-postgresql-update-rake-tasks-to-use-full-settings-from-database-yml-bugfix

I'm trying to connect to a postgres schema other than "public" within my test environment, but it seems ActiveRecord is overwriting the schema_search_path to "public" due to this commit - inconvenient. I have a very complex postgres database which requires schemas for adequate testing.

Link to original bug: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/170-postgresql-update-rake-tasks-to-use-full-settings-from-database-yml-bugfix

@tarmo

This comment has been minimized.

Show comment
Hide comment
@tarmo

tarmo Nov 5, 2011

Contributor

These connections are only used for creating and dropping a database and the connections aren't even made to your configured database but to the 'postgres' database which is expected to have the 'public' schema. https://rails.lighthouseapp.com/projects/8994/tickets/170

Contributor

tarmo replied Nov 5, 2011

These connections are only used for creating and dropping a database and the connections aren't even made to your configured database but to the 'postgres' database which is expected to have the 'public' schema. https://rails.lighthouseapp.com/projects/8994/tickets/170

@nicb

This comment has been minimized.

Show comment
Hide comment
@nicb

nicb Jan 15, 2012

What if someone has to deal with a legacy postgres db which actually has some schema other than public? I could submit a patch to the database task to figure the schemas needed to be re-created, but I am not sure whether there isn't a very good reason to do so that I am not aware of (since it should be a pretty easy and useful thing to do). If someone can clarify why this feature is not already available, I am willing to put some work into it.

nicb replied Jan 15, 2012

What if someone has to deal with a legacy postgres db which actually has some schema other than public? I could submit a patch to the database task to figure the schemas needed to be re-created, but I am not sure whether there isn't a very good reason to do so that I am not aware of (since it should be a pretty easy and useful thing to do). If someone can clarify why this feature is not already available, I am willing to put some work into it.

@nicb

This comment has been minimized.

Show comment
Hide comment
@nicb

nicb Jan 21, 2012

Is there any chance that this issue gets looked up and re-opened? Otherwise rake test:units is simply not usable.

nicb replied Jan 21, 2012

Is there any chance that this issue gets looked up and re-opened? Otherwise rake test:units is simply not usable.

@tenderlove

This comment has been minimized.

Show comment
Hide comment
@tenderlove

tenderlove Jan 23, 2012

Member

@nicb would changing the search path based on environment variable be acceptable? I would accept a patch for that. :-)

Member

tenderlove replied Jan 23, 2012

@nicb would changing the search path based on environment variable be acceptable? I would accept a patch for that. :-)

@nicb

This comment has been minimized.

Show comment
Hide comment
@nicb

nicb Jan 23, 2012

I would definitely think so, since there is already a schema_search_path key in the config/database.yml, that key could indeed be re-used in the rake task instead of flattening it to public. I will give it a try as soon as I get a chance to do it and report back (and provide a patch if I get to somewhere functional).

nicb replied Jan 23, 2012

I would definitely think so, since there is already a schema_search_path key in the config/database.yml, that key could indeed be re-used in the rake task instead of flattening it to public. I will give it a try as soon as I get a chance to do it and report back (and provide a patch if I get to somewhere functional).

@tarmo

This comment has been minimized.

Show comment
Hide comment
@tarmo

tarmo Jan 23, 2012

Contributor

@nicb Sorry I couldn't be of more help here. Wondering about your legacy database though, why does it not have a 'public' schema in the 'postgres' database, was the database created before postgresql implemented schemas, or was another schema name intentionally used? Any reason you can't just create an empty 'public' schema for the 'postgres' database? (in case it isn't clear, the schema is just needed to connect to postgresql, it has nothing to do with the specific database for rails that is being created or deleted using that connection).

Contributor

tarmo replied Jan 23, 2012

@nicb Sorry I couldn't be of more help here. Wondering about your legacy database though, why does it not have a 'public' schema in the 'postgres' database, was the database created before postgresql implemented schemas, or was another schema name intentionally used? Any reason you can't just create an empty 'public' schema for the 'postgres' database? (in case it isn't clear, the schema is just needed to connect to postgresql, it has nothing to do with the specific database for rails that is being created or deleted using that connection).

@nicb

This comment has been minimized.

Show comment
Hide comment
@nicb

nicb Jan 23, 2012

The database I'm working with has already been in production for several years. They had an 'old implementation' of the database in the public schema, and they did a new implementation using a different schema name. That sounds silly perhaps, but 'they' is somebody I don't know so I can't even ask why they did it this way. Since I cannot change the structure of the production database, I have two options:

  1. use a different schema (using only public) for the testing suite
  2. try to fix this issue
    I could easily do (1) but I don't think it is the correct way to go. If the ruby pg adapter supports schemas and the rails implementation supports schemas (which it does, since you can define them in configuration), then we should be able to run tests on the database configured for tests as it is for production. Also because otherwise these tests are missing one important point which could crop up in production.

I am starting to think how to fix it. The super-easiest fix of them all is to set an environment variable like:

   sspath = ENV['PG_SCHEMA_SEARCH_PATH'] || 'public'
   ....
   ActiveRecord::Base.establish_connection(config.merge('database' => 'postgres', 'schema_search_path' => sspath))

I don't know if that is enough to actually do the job properly. I am proposing it here to you before checking it to bar probable naiveties on my side.

nicb replied Jan 23, 2012

The database I'm working with has already been in production for several years. They had an 'old implementation' of the database in the public schema, and they did a new implementation using a different schema name. That sounds silly perhaps, but 'they' is somebody I don't know so I can't even ask why they did it this way. Since I cannot change the structure of the production database, I have two options:

  1. use a different schema (using only public) for the testing suite
  2. try to fix this issue
    I could easily do (1) but I don't think it is the correct way to go. If the ruby pg adapter supports schemas and the rails implementation supports schemas (which it does, since you can define them in configuration), then we should be able to run tests on the database configured for tests as it is for production. Also because otherwise these tests are missing one important point which could crop up in production.

I am starting to think how to fix it. The super-easiest fix of them all is to set an environment variable like:

   sspath = ENV['PG_SCHEMA_SEARCH_PATH'] || 'public'
   ....
   ActiveRecord::Base.establish_connection(config.merge('database' => 'postgres', 'schema_search_path' => sspath))

I don't know if that is enough to actually do the job properly. I am proposing it here to you before checking it to bar probable naiveties on my side.

@tenderlove

This comment has been minimized.

Show comment
Hide comment
@tenderlove

tenderlove Jan 24, 2012

Member

The other option is that we could have a schema section in the configuration file. Rails could use the regular settings (the current defaults), or override if a schema configuration is present. Having a schema configuration would probably be cleaner, but I'm fine with an environment variable too.

Member

tenderlove replied Jan 24, 2012

The other option is that we could have a schema section in the configuration file. Rails could use the regular settings (the current defaults), or override if a schema configuration is present. Having a schema configuration would probably be cleaner, but I'm fine with an environment variable too.

@tarmo

This comment has been minimized.

Show comment
Hide comment
@tarmo

tarmo Jan 24, 2012

Contributor

@nicb could you try if just removing the 'schema_search_path' from the establish_connection line make this work for you? In shouldn't really matter what the schema search path is while running "create database" and "drop database" queries.

Contributor

tarmo replied Jan 24, 2012

@nicb could you try if just removing the 'schema_search_path' from the establish_connection line make this work for you? In shouldn't really matter what the schema search path is while running "create database" and "drop database" queries.

Please sign in to comment.