Re: [sqlalchemy] 'ThreadLocalMetaData' support for 'schema'
Thanks for the reply Michael. I had already done some experimentation with
the 'Session.after_begin' event, so I think I'll revisit that for now, but
#2685 looks like a very elegant solution, looking forward to that.
--Pedro.
On Sunday, 7 April 2013 15:44:55 UTC+1, Michael Bayer wrote:
>
> we will be supporting this as a connection execution option in
> http://www.sqlalchemy.org/trac/ticket/2685, so the usage will be like:
>
> conn = connection.execution_options(default_schema=someschema)
> s = Session(bind=conn)
>
> < work with Session or Connection >
>
>
> for now the easiest approach is to set the search path per
> connection/session/whatever:
>
> s = Session()
>
> s.execute("set search path to my_schema, public")
>
> if you bind your Session to a Connection as above, it will be used
> repeatedly for new transactions so the commit() won't be a problem.
>
> Another approach, if you're Session centric, is to set it in the
> after_begin Session event:
>
> from sqlalchemy import event
>
> @event.listens_for(Session, "after_begin")
> def after_begin(session, trans, conn):
>conn.execute("set search path to my_schema, public")
>
>
>
> On Apr 7, 2013, at 6:09 AM, Pedro Romano >
> wrote:
>
> Having to support different PostgreSQL schemas per web request and finding
> my current approach of setting the PostgreSQL schema search path a bit
> convoluted, when I try to use longer lived sessions in unit tests
> for convenience, because the session starts using a new database connection
> after a commit, I came across 'sqlalchemy.schema.ThreadLocalMetaData'
> which would seem to be an elegant solution for the problem if it supported
> a different 'schema' per thread as it does a different 'bind'.
>
> My question is: would it be feasible and does it make sense to 'schema'
> support to 'sqlalchemy.schema.ThreadLocalMetaData' for cases such as the
> one I described above?
>
> Thanks in advance for any feedback on this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy+...@googlegroups.com .
> To post to this group, send email to sqlal...@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] 'ThreadLocalMetaData' support for 'schema'
we will be supporting this as a connection execution option in
http://www.sqlalchemy.org/trac/ticket/2685, so the usage will be like:
conn = connection.execution_options(default_schema=someschema)
s = Session(bind=conn)
< work with Session or Connection >
for now the easiest approach is to set the search path per
connection/session/whatever:
s = Session()
s.execute("set search path to my_schema, public")
if you bind your Session to a Connection as above, it will be used repeatedly
for new transactions so the commit() won't be a problem.
Another approach, if you're Session centric, is to set it in the after_begin
Session event:
from sqlalchemy import event
@event.listens_for(Session, "after_begin")
def after_begin(session, trans, conn):
conn.execute("set search path to my_schema, public")
On Apr 7, 2013, at 6:09 AM, Pedro Romano wrote:
> Having to support different PostgreSQL schemas per web request and finding my
> current approach of setting the PostgreSQL schema search path a bit
> convoluted, when I try to use longer lived sessions in unit tests for
> convenience, because the session starts using a new database connection after
> a commit, I came across 'sqlalchemy.schema.ThreadLocalMetaData' which would
> seem to be an elegant solution for the problem if it supported a different
> 'schema' per thread as it does a different 'bind'.
>
> My question is: would it be feasible and does it make sense to 'schema'
> support to 'sqlalchemy.schema.ThreadLocalMetaData' for cases such as the one
> I described above?
>
> Thanks in advance for any feedback on this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy+unsubscr...@googlegroups.com.
> To post to this group, send email to sqlalchemy@googlegroups.com.
> Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] 'ThreadLocalMetaData' support for 'schema'
Having to support different PostgreSQL schemas per web request and finding my current approach of setting the PostgreSQL schema search path a bit convoluted, when I try to use longer lived sessions in unit tests for convenience, because the session starts using a new database connection after a commit, I came across 'sqlalchemy.schema.ThreadLocalMetaData' which would seem to be an elegant solution for the problem if it supported a different 'schema' per thread as it does a different 'bind'. My question is: would it be feasible and does it make sense to 'schema' support to 'sqlalchemy.schema.ThreadLocalMetaData' for cases such as the one I described above? Thanks in advance for any feedback on this. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
