For ActiveRecord it's okay to use a before filter rather than an around
one. But for Sequel you'd probably need to call "with_connection {|c| ...}".
Since ActiveRecord will reserve the connection for the full request
cycle, you're okay with using a before filter as long as you don't spawn
new threads using the database in your request main thread.
Even if you're not using a multi-process server (like Unicorn) it should
just work fine in the conditions stated above.
Cheers.
On 02-06-2014 00:49, Reginaldo Junior wrote:
Yes. Actually I'm using a before filter and setting it per
requisition. I think it will work because I'm using Unicorn. But I'm
curious why are you suggesting an around filter, what should I do
after the action? I think I'm missing something.
Em domingo, 1 de junho de 2014 18h33min48s UTC-3, Rodrigo Rosenfeld
Rosas escreveu:
I guess you want to implement some kind of multi-tenant
application using PG separate schemas for each tenant.
In that case, if your application uses a single thread per request
you should be able to achieve that by using an around filter to
set the search path.
I think this is the easiest way to achieve what you want if I
guessed it correctly.
On 01-06-2014 18:14, Reginaldo Junior wrote:
Can I do this dinamically and is it thread-safe?
Em domingo, 1 de junho de 2014 17h48min27s UTC-3, Mohamed Wael
Khobalatte escreveu:
This is achievable by setting the table in the model Bar to
foo.bar, is that what you meant?
On Sun, Jun 1, 2014 at 9:14 PM, Reginaldo Junior
<[email protected]> wrote:
Hi. I was thinking in the possibility to set a namespace
for tables in AR queries, so instead of setting the
search path like this:
ActiveRecord::Base.connection.schema_search_path =
'foo, public'
We specify the schema in the query:
select * from foo.bar;
so it could be a thread-safe solution and work with
multi-thread environments and improve Rails support for
real multi-tenant apps using Postgres schemas. What do
you guys think?
--
You received this message because you are subscribed to
the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to [email protected].
To post to this group, send email to
[email protected].
Visit this group at
http://groups.google.com/group/rubyonrails-core
<http://groups.google.com/group/rubyonrails-core>.
For more options, visit
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
Mohamed Wael Khobalatte
--
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected] <javascript:>.
To post to this group, send email to [email protected]
<javascript:>.
Visit this group at
http://groups.google.com/group/rubyonrails-core
<http://groups.google.com/group/rubyonrails-core>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
