[Victor Safronovich]
> there is a proposal to import transaction._transaction.Status instance
> to transaction package namespace and use in Zope for example
>
> from transaction import get, Status
>
> class Test:
> def __del__(self):
> if get().status = Status.Commited:
> print 'commited'
> else:
> print 'not commited'
>
> REQUEST._hold( Test() )
Not in its current state. There are no docs beyond a few code comments:
class Status:
# ACTIVE is the initial state.
ACTIVE = "Active"
COMMITTING = "Committing"
COMMITTED = "Committed"
# commit() or commit(True) raised an exception. All further
# attempts to commit or join this transaction will raise
# TransactionFailedError.
COMMITFAILED = "Commit failed"
Even those are no longer wholly accurate (someone-- reasonably! --added
savepoint creation to the set of possible ways to get into COMMITFAILED
status, but didn't update the comments above to say so).
ZODB has gotten into a lot of trouble historically by "exposing" fuzzy,
undocumented internal implementation details. _transaction.Status is
exactly that right now. If it's to be exposed, the _meaning_ of these
states, and the possible transitions among them, have to be carefully
documented first. I'm not even sure it's a reasonable set of states to
expose -- for example, why is there no state corresponding to transaction
abort? (The answer is that _transaction.py doesn't happen to need such a
state, and since it _is_ an internal implementation detail now it doesn't
have to care whether its internal reasons make good sense outside of the
Transaction implementation.) There also needs to be agreement that all
future implementations of transactions will implement the documented
semantics (nothing is solely "a feature", it's also a set of constraints on
future implementations).
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
