Thanks Michael, that gives me more understanding of using the session.
Actually the DBSession is initialized from:
DBSession = scoped_session(sessionmaker(
extension=ZopeTransactionExtension()))
as the following description:
ZopeTransactionExtension is a little piece that makes sure every session
that opens joins an active transaction. So if you were to open 5 session's,
they will all join the same transaction. That way if you commit or rollback
the transaction, all the work done by the either of the 5 sessions will
follow suit. The transaction module ("transaction.commit()") is key here.
pyramid_tm tries to make setting up a transaction straightforward ... it
starts one upon request entry, all scoped database sessions join it... and
then at the end of the request, if it discovered an error, it will rollback
the transaction. Otherwise, the transaction will be committed. That way
view-level code never has to create or close/commit/rollback the transaction
manually.
Mostly session.flush() is for making sure your database model instances get
their primary keys filled in without committing the transaction.
So inside a view all you gotta do is:
def myview(request):
session = DBsession()
session.add(model)
pyramid_tm will make sure session is committed or rolled back appropriately.
The session's discussion always makes me confusion, what about in my "model"
I define something like this:
def foobar(self, session.....):
session.add(self)
On Fri, Sep 2, 2011 at 6:58 AM, Michael Bayer <mike...@zzzcomputing.com>wrote:
>
> On Sep 2, 2011, at 3:02 AM, Wichert Akkerman wrote:
>
> > On 09/02/2011 03:31 AM, Michael Bayer wrote:
> >> With SQLAlchemy you should have an ongoing transaction/session defined
> externally to individual operations on your mapped objects - SQLA uses the
> "unit of work" pattern which specifically is about grouping related
> persistence/query operations together. The usage you have above is still
> thinking in the "active record" style of things - "session per individual
> persistence operation" - and won't take full advantage of SQLA's way of
> doing things.
> >
> > I can see this being useful if you need a id generated by a serial
> though. In places where I need something like that I use
> object_session(self), which seems to work well.
>
>
> OK let me clarify - it is *entirely OK*, even encouraged, to make usage
> of the Session inside of object methods. object_session(self) to do
> queries, add() more things, as well as using a contextual Session to add()
> new objects from within a @classmethod. This is commonplace and necessary.
> Use Sessions freely anywhere and everywhere.
>
> What is *usually not needed*, is to create a brand new Session inside of an
> object method, and then to commit() the transaction it uses. Usually,
> there should be an external context that all objects are interfacing with,
> i.e., a Session. If you don't have an ongoing context at all, and are
> adding "x = Session(); x.add(self); x.commit()" inside of all your methods
> as the normal way of doing things, that is definitely the wrong way to do
> it.
>
> The case where you *may* want to build a brand new Session and commit it
> inside of a method is when you specifically want some operation to occur in
> a transaction that is distinct from everything else that's going on ; I use
> such a notion to write operations to a "logging" table in my app, so that a
> web GUI can read that one table for status while some long operation is
> going on, and also so that the log of activity remains if the long running
> operation fails, and the transaction is rolled back. But even in that case,
> I have a single function in my app called log() that's at the module level
> which does this (with lots of behavioral options).
>
> The main thing I want to get across is, all apps should ideally have some
> standard, defined-in-only-one-or-two-places system of initiating Sessions
> and establishing where the scope of that Session ends for the majority of
> operations, and you should catch yourself if you're trying to avoid building
> that pattern that for some reason.
>
> --
> 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
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
>
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
