I think the base Session concept needs to be extremely simple, and I would
rather have it less flexible rather than too complicated. as you noted,
developers with more sophisticated needs are free to subclass Session, and
make their own transactional scoping rules by playing around with
UnitOfWork objects. we can even have a collection of "Session" plugins in
the extensions package, each one designed to meet a different developer's
idea of how to organize transactions. so a simplistic design is not going
to hold anyone back, there can be choices.
another point is, with regards to "rollback" there are two completely
distinct rollback concepts in this thing right now, one which is to just
cancel the UnitOfWork object that has collected "new", "dirty", and
"deleted" items and lists, and the other is a function of the attributes
system which can "reset" the individual attributes on an object. While
the former is reasonable, the latter is kind of a curiousity right now,
and has already confused people (as it is not a true "roll back" of the
entire in-memory state), so I have pretty much been de-emphasizing that
little trick and not really documenting it, since its essentially not very
useful except perhaps for some very specific situation. if you really
want to discard your changes in a unit of work, you should probably start
all over again from when you created/loaded your initial field of objects.
back to begin/commit, id rather go for something totally simple, like:
def func(s):
# do stuff
s.commit() # commit
# ordinary function calls, they all can commit as they go.
s = objectstore.get_session()
func(s)
# start a transaction,
# functions can call s.commit() but nothing happens
# until the "transaction" is committed
s = objectstore.get_session()
trans = s.begin()
func(s)
trans.commit()
So in simplistic case #1, nobody needs to know anything, its just
s.commit(). functions can commit as they go, or use their own
begin/commits. in less simplistic case #2, a "baton" object is the
ultimate controller of the transaction, and only the outermost caller
needs to know about it, functions can do whatever style of commit they
want. Once you get that initial "trans", all regular calls to s.commit()
do nothing, nor do any further s.begin() calls...only the trans can commit
it, thereby ending the block.
as for everything else, id like to proceed more slowly and wait for
specific developer issues to come in before making too many changes. also
with regards to the SessionError class, Id like to address "exception"
classes across the entire application in one pass, i.e. create an
exceptions package/hierarchy and nail down the full behavior to be used
across the whole thing....my exceptions are all string-based right now
simply because i wanted the library to take shape before I could decide
how exceptions should look.
- mike
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
