On Jun 18, 12:12 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jun 18, 2008, at 11:43 AM, Hans wrote:
>
>
>
> > Now, if I want to do some stuff with the engine or connection
> > directly, should I create my engine with context="threadlocal"
> > additionally? (And then pass that threadlocal engine off to my
> > scoped_session ?)
>
> if you deal with the engine, it uses connection resources on an as
> needed basis, such as when you say engine.execute(somestatement). the
> "threadlocal" context doesn't really grant any additional "thread
> safety", its just a convenience method so that operations common to a
> thread can all implicitly share a transaction without the need to pass
> an explicit Connection object. It is typically useful in a non-ORM
> oriented application. In an ORM oriented application, the Session
> tends to be the home base for transactional/database context.
Ok, I think I understand that. So "threadlocal" basically let's the
Engine reuse connection objects and is really for "implicit"
connections rather than creating and using connections explicitly.
> Im not entirely sure what you mean by "pass that engine to my
> scoped_session". You typically bind the underlying sessionmaker() to
> an engine when its first created, "threadlocal" or not, and you're done.
Yeah, that's what I meant -- I would bind the threadlocal engine to
the sessionmaker in the app setup phase.
> > And when I get a connection from such an engine, do I need to always
> > specify that I want a contextual connection? i.e. conn =
> > engine.contextual_connect() ? (What happens if I just run
> > engine.connect() as "normal" with a threadlocal connection?)
>
> the difference between connect() and contextual_connect() is only
> significant if you're using the "threadlocal" context. I would advise
> not using "threadlocal" for now as you should familiarize with the
> basics first. If you are using Connections, its best to stick with
> connect(). contextual_connect() is only for applications that are
> trying to interact with the engine in such a way that they participate
> within the "threadlocal" context if used that way. But normally you
> wouldn't use explicit Connections with "threadlocal" since the whole
> point of "threadlocal" is to remove the need to pass around Connection
> objects.
Ok, this makes sense. I guess I don't need to worry about the
threadlocal stuff if I'm always creating and disposing of connections.
For example, if I have a DAO method (classmethod) that peforms some
custom SQL query, it sounds like the clean & simple way to do this
would be to just create and dispose of the connection within that
method. Then I don't need to worry about thread safety issues
(right?).
def get_some_data(cls, params):
conn = engine.connect()
rs = conn.execute('stored proc or complex SQL here')
return rs
(And then close connection via rs.close() in calling code, for
example.)
On a follow-up note, If I am creating a new connection (calling
engine.connect()) for every method, will that actually be creating a
new connection (assuming I'm not using strategy="threadlocal")? If
so, is there a better convention? -- I assume that something like a
singleton pattern would be right out, since that would imply sharing
between threads.
> I would comment that if you are working with ORM transactions and wish
> to have direct execute() access within the context of that
> transaction, you're best sticking with the execute() and connection()
> methods off of Session itself; this will ensure that those operations
> are participating with whatever transaction the current Session may
> have in progress.
Yeah, for the ORM stuff, I definitely plan to stick with the
ScopedSession and let that handle it all for me. We have a lot of
legacy SQL at this point and for the sake of simplicity (and also
because rewriting some of this SQL is not going to be any prettier
with the sql builder api) it will be necessary to use connections
directly for some components of the application.
Thanks again for the help in understanding this.
Hans
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
