[dev] RFC: Transaction meta data

Jim Fulton <[email protected]>
Newsgroups gmane.comp.web.zope.zodb
Message-ID <CAPDm-FizE9-fQ+E5J9GS3Cy1H_SFX0ZBEucJx0bnv5vOM_EpQg@mail.gmail.com>
Recently, I tried to clean up transaction meta data:

https://groups.google.com/forum/#!topic/python-transaction/Yn326XwCZ5E

https://github.com/zopefoundation/transaction/pull/28

This opened a small can of worms. The existing storage APIs are vague about
whether the user and description field are text/unicode or bytes.
Historically, they've been bytes, but storage implementations are defensive
and allow either, although they're also conservative and, if given text,
encode using an ASCII encoding.

For a while I've realized that storages should be asked to do less than
they do now, and that more should be done by ZODB.

In that spirit, I'm inclined to say that transaction user and description
should be encoded by ZODB, using UTF-8 and that storages should only deal
with bytes.  Eventually, storages can be less defensive.

(I meant to and thought I'd sent this earlier. While waiting for the
response...)

I've updated the ZODB interfaces on a branch:

https://github.com/zopefoundation/ZODB/compare/storage-byte-appreciation#diff-881ceb274f9e538d4144950eefce8682

This defines an interface, IStorageTransactionMetaData, that specifies
these data as bytes.  ZODB will build an object implementing this interface
as pass it to storages rather than passing transaction objects.

I've also defined IStorageTransactionMetaDataExtensionBytes, which has
serialized extension data. This can be used to take responsibility for
serializing extension data off storage hands.  (I need this for byteserver,
but I think it will be beneficial in a small way for other storages.)

Jim

-- 
Jim Fulton
http://jimfulton.info

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.