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.

On Thursday, May 19, 2011 3:46:29 AM UTC-6, sleepwalker wrote:

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?