rails 3 and postgresql scemas

Does Rails 3 support native working with postgresql schemas, or I should try some own solution?

I have some already-created postgresql database with 4 or somth schemas. By putting "schema_search_path: ejabber, public, admin, statistic" into database.yml I told Rails that I have more than 1 schema. When I make "rake db:schema:dump" I have tables from all 4 schemas alphabetical with no schema-dependency.

So the question is, when I'll be ready to deploy my app on production (via capistrano, for example), is there would be still 4 schemas in database, or only one? How does Rails keeps knowing which table belongs to which schema?

First a disclaimer: I’m no expert on using PostgreSQL w/rails. So, take this with a grain of salt. Hopefully someone w/more knowledge will respond.

Does Rails 3 support native working with postgresql schemas, or I

should try some own solution?

As you’ve discovered it has some but obviously isn’t complete.

I have some already-created postgresql database with 4 or somth

schemas.

By putting “schema_search_path: ejabber, public, admin, statistic”

into database.yml I told Rails that I have more than 1 schema.

When I make “rake db:schema:dump” I have tables from all 4 schemas

alphabetical with no schema-dependency.

This, however, would definitely seem to be a problem to me. Perhaps you could report it as a bug?

So the question is, when I’ll be ready to deploy my app on production

(via capistrano, for example), is there would be still 4 schemas in

database, or only one? How does Rails keeps knowing which table

belongs to which schema?

This depends. You say you’ve already got a database. By this, do you mean you’ve already got a “development” database but that you’d be instantiating a new one for production? Or, is your existing database a production database?

If it’s production, then the fact that the schema-dumping code drops postresql schema information won’t be a problem because you won’t be using this dumped schema information to create a production database. I think (grain of salt) it would just work since (hopefully) the postgres adapter will otherwise work fine when “addressing” your tables in the constructed SQL queries.

However, if you’re dumping schema from an existing “development” database so that you can use it to create a production database, then you’ll have problems (unless, of course, you have no table name collisions in which case it might just create all tables in the “public” schema and work, even if not in the configuration (multi-schema) you want).

We accomplish this with custom extensions to the PostgreSQLAdapter, Migration, Migrator and other classes. It is not an ideal solution because we have to patch numerous areas including rspec.rake tasks, database_cleaner rake task and we still dont have a full solution that behaves like you would expect a 'standard' rails app to behave. Furthermore this can create an opaque codebase and confusion for new developers.

Having recently upgraded from Rails2.3.5 to Rails3.0.6 I had to rewrite our rspec tasks and bigfix our Adapter code - but considering the overall complexity of the upgrade, this was a small overhead.

In our case, we have a dozen engines often with their own models and migrations. So we have decided that each engine would have its own namespace. So user information would be in the 'identity' namespace for example.

I'd love to hear of more support postgresql schemas in rails. Are other databases - is mysql better supported?