On Jun 18, 1:18 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jun 18, 2008, at 12:41 PM, Hans wrote:
>
>
>
> > 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
>
> you could just as easily use engine.execute() for a case like the
> above, which does basically the same thing. theres no thread safety
> issues inherent.
Ok, that's good to know. I thought that somehow that was for more ORM-
related queries (or, rather, using the metadata Tables). So I suppose
the only reason I'd need to work with a Connection is if I wanted the
transaction control. For most of my single-statement cases, I don't
care about the transactions (or rather, want them to happen in single
transaction).
> > 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.
>
> when you say engine.connect() it draws the connection from the
> connection pool. So whether or not a new connection is "created" at
> that point depends on the configuration and current state of the pool.
Ok, that's what I suspected, but wanted to make sure I understood that
correctly. I read the section on connection pooling, but that seemed
to involve wrapping the low-level driver (e.g. psycopg) with a proxy
object. Not sure if that's a completely different beast. In any
event, it sounds like I can worry about the pooling (and general
resource performance) at a later point in the development -- and make
those change w/o having to change the API my app uses to get
connections at all.
Thanks again -
Hans
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
