Not mentioned anywhere is that the PostgreSQL adapter now supports using the Schema Search Path without fistfuls of bugs and oversights.
I'm using schema separation for a multitenant application, and it looks like I'll be able to remove at least 4/6 hacks to make rails support that functionality.
Also, if it is not much to ask, I know this is not the topic, but could you describe how you make this kind of separation? I have the same requirements for isolation and your experience in the matter would be valuable. :)
I remember reading your post some time ago, it really helped me creating a better view of this solution and is in fact our preferred method thanks to it. I still haven't implemented it for real and it would be great, if not much to ask you, if you could elaborate the impact of these changes in a post update? What do you think?
Sure. Basically, I have a schema called template_tenant, and a table public.tenants (ie. in the public schema). For each record with id n in the public.tenants table, I have another schema tenant_n cloned from and kept in sync with the template_tenant schema.
The result of this is that I have dozens of tables duplicated across n schemas. In Rails 3.1, the Postgres query cache, exec cache, and the identity map do not account for this, nor does table_exists?, and the connection pool would often check out a new connection without preserving the search path.
In Rails 3.2, most of these are fixed. The exec cache, query cache, and table_exists? now observe the search_path properly, and I believe the connection pool behaves better, though I haven't had time to confirm that. The identity map still doesn't understand, which I've filed an issue for: https://github.com/rails/rails/issues/4044
I'm really happy with this pattern for multi-tenant apps. It gives me a lot more confidence that no data leaks will happen than scoping queries, and the performance increase is significant with large datasets (unless of course, for some reason, you need to aggregate across tenants). It's nice to see rails supporting this better.
The sixth patch I had hacks support for iterating over multiple schemas to migrations. I add "schema_set :public or :tenant" to the top of my migration, and it runs either once on the public schema, or n+1 times on my template_tenant schema and my tenant_X schemas. It wouldn't make sense for this part to be in rails proper at the moment.
I'm using schema separation for a multitenant application, and it looks like I'll be able to remove at least 4/6 hacks to make rails support that functionality.