Responses inline. On Monday, 15 July 2013 14:14:04 UTC-7, Jonathan Vanasco wrote:
> > > Someone posted a docs suggestion to -devel, which made me look at the > current sqlalchemy scaffold. > > > I'm not sure it's 'correct' > > > a few weeks ago I asked Mike Bayer (sqlalchemy) what the best practices > for webapps were ( > https://groups.google.com/forum/#!topic/sqlalchemy/ZsHxDzlATCQ ) > > > he responded with two links: > > > fairly recently i wrote up as much as I could come up with on this, which >> you can see first in the Session FAQ: >> >> http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html#session-frequently-asked-questions >> >> >> and then regarding scoped_session in: >> >> http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html#using-thread-local-scope-with-web-applications > > > > the big thing that i'm picking up off the current scaffold, is that > there's a single scoped_session as DBSession in models.py ( > https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/alchemy/%2Bpackage%2B/models.py_tmpl > ) > , while the views.py uses that same session ( > https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/alchemy/%2Bpackage%2B/views.py_tmpl > ) > > the scaffold seems to not invalidate the local sqlalchemy session , or > suggest that a new one is created. > > I've not used the scaffold myself, but invalidation is handled by zope.sqlalchemy which ties SQLAlchemy into Pyramid's request lifecycle with pyramid_tm. > It's my understanding that a few things should happen instead ( which are > basically covered in the cookbook ) > > > a) if a 'global' `DBSession` is used within a view, is should be > explicitly instantiated to create a new thread/request local instance > `DBSession()` > and/or > > b) you could opt to be even more explicit and use tween to prep the > session ( or use add_request_property ) -- but that setup action should > also run a add_finished_callback to `remove` (invalidate) the session after > the request. > > > in pseudocode , something like.... > > def ScopedSession_cleanup(request): > request.ScopedSession.remove() > > def tween_factory(handler, registry): > def tween(request): > request.ScopedSession = ScopedSession() > request.add_finished_callback(ScopedSession_cleanup) > return tween > > getting to the nuts and bolts: > > 1- > http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/database/sqlalchemy.html#using-a-non-global-session > > "def cleanup():" would be better to have `session.remove()`, not > `session.close()` > > zope.sqlalchemy does a ``session.close()``. It does not have a handle on the ScopedSession object which has the ``DBSession.release()`` method. This does miss out the ``DBSession.clear()`` of the release method, but that hasn't been a problem for me. I don't really understand the purpose of this recipe. As far as I can tell, scoped sessions should work in an async system just fine as gevent.monkey.patch_thread() just patches threading so the scoped session will become greenlet local instead of thread local. > 2- > https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/alchemy/%2Bpackage%2B/views.py_tmpl > > bad : > "one = DBSession.query(" > > better : > "local_session = DBSession()" > "local_session.query(" > > it might also make sense to replace `DBSession` with `DBSessionFactory`. > > thoughts ? > I do prefer the ``session = DBSession()`` pattern myself. The SQLAlchemy docs consistently refer to the scoped session factory as capitalized ``Session`` and the thread local session as lowercased ``session``. I think sticking fairly closely with the conventions from SQLAlchemy docs is worthwhile so don't see the point in changing to ``local_session = DBSessionFactory()``. The Session -> DBSession naming is probably worthwhile to avoid confusion with Pyramid's completely unrelated request.session. Laurence (zope.sqlalchemy author) -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
