Pretend I bound that metadata and session to an engine at some
point...
On Jun 3, 12:59 pm, Nick Retallack <nickretall...@gmail.com> wrote:
> On Jun 3, 8:53 am, Michael Bayer <mike...@zzzcomputing.com> wrote:
>
> > > Is it a common practice to pass the current session into the
> > > constructor of an ORM model?
>
> > no. The session consumes your objects, not the other way around. An
> > object can always get its current session via object_session(self).
>
> > > At this point, it can't be in a session
> > > yet, so Session.object_session(self) wont help you. So what if the
> > > constructor needs to do some queries, perhaps to find-or-create some
> > > related models? Is this why pylons uses threadlocal sessions?
>
> > the scoped session does serve as a way for all areas of an application to
> > get to "the session", yes. But methods on an object should probably use
> > object_session(self) for portability.
>
> Can you explain how this would work? Here's a contrived example to
> illustrate my problem:
>
> class Thing(object):
> """A user-facing class"""
> def __init__(self, color):
> # what if I wanted to do something like this? Where would
> this session come from? A thread-local?
> color = session.query(Color).filter_by(name=color) or
> Color(color) # find-or-create
> color.count = color.count + 1
> self.color = color
>
> class Color(object):
> """This class is just there to count things"""
> def __init__(self, name):
> self.name = name
> self.count = 0 # number of things of this color
>
> metadata = MetaData()
> things_table = Table('things', metadata, autoload=True)
> mapper(things_table, metadata, Thing)
> mapper(colors_table, metadata, Color)
>
> session = Session()
> thing = Thing(params) # Thing.__init__ doesn't know about the session
> at this point
> session.add(thing)
> session.commit()
> session.close()
>
> > > The problem gets worse if you're
> > > running those applications with multiple processes or instances,
> > > because then you really have no idea how many connections there could
> > > be.
>
> > you have an exact idea. The max size of the pool is deterministic and
> > explicit.
>
> Just to be perfectly clear, the number of connections it will maintain
> is equal to the number of processes * pool_size, right? (or the
> number of processes * (pool_size+max_overflow) for the maximum
> possible connections).
>
> > > Would it be better to use a connection pooling solution external to my
> > > python applications? One that had shared knowledge of all of them?
>
> > the django camp is big on pgpool. To me it seems unnecessary. I've run
> > applications that spawn off lots of child forks, the child forks typically
> > use one session for the life of the subprocess, so its pretty much one
> > connection per subprocess. I don't see why it needs to be any more
> > complicated than that. If your child processes are using more
> > connections than they should be, pgpool doesn't solve that, you should
> > usually have one connection per process per thread.
>
> > > If I'm running a web application with fastcgi, I'm already affected by
> > > this framentation of connection pools, right? Considering fastcgi
> > > uses multiple processes. Should I set my pool size to the size I
> > > expect only a single process to use? I wouldn't expect a single
> > > process to use more than one connection at a time, if no threading is
> > > going on.
>
> > that's correct, so if you limit the pool size to exactly 1 with no
> > overflow, you'll get an error and a stack trace at immediately the point at
> > which your app is opening a second connection, so that it can be corrected.
>
> So if I never intend to use multi-threading or multiple persistent
> sessions, I should always set the pool_size to 1? Is that what you do?
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
