[ZODB-Dev] Transaction note interface

[Christian Theune]

Am Di, den 31.08.2004 schrieb Tim Peters um 20:13:
> [Christian Theune]
> > I just ran into a problem forcing me to programm around the API for
> > transactions. A very long running transaction created a lot of notes for
> > it going over the 65k limit. I now need to to
> >
> > get_transaction().description = 'my short note'
> >
> > to be able to commit this transaction in FileStorage.
> >
> > What about giving note() an optional parameter to not append the note,
> > but set the note to this exact value?
> 
> We could, but it doesn't seem to address the original problem.  That is, you
> would still have no way to guess in advance whether the accumulated notes
> are "too big".

Right.

> It's clear from the implementation that notes() doesn't expect to see more
> than a few relatively short strings per transaction (the implementation
> requires time quadratic in the number of notes added in a transaction).

Is it number of notes or size of the accumulated note? Number of notes
would be quadratic in the notes() function, but I can't see it there ...

> Maybe it would be better if storages with a limit on description size
> automatically cut back (presumably rare) over-long descriptions instead of
> raising an exception long after it's too late for the user to "do something"
> about that.  Ditto for the user metadata.

Well. I think this would be a feasable option, as the moment this caught
me was during the automated generation of content for a plone site that
involved bout 150 (content) objects + workflow actions. The one thing I
was surprised was that the note() function is accumulating.

> There's also Transaction.setExtendedInfo().  I don't know why it exists, and
> it appears Zope never uses it.  It creates a dict under the covers, and that
> also gripes if the pickle of the dict is >= 64KB.  If anything does use
> this, auto-reducing its size probably isn't justifiable.  I'm not sure
> anyone would care if FileStorage cut arbitrary stuff out of a giant
> description or user path.

I _think_ I saw setExtendedInfo beeing used in a couple of 3rd party
products. 

The thing that might really be annoying to people is that Storages are
the problem here. It sounds like a rather arbitrary limit. (The unit
tests should have catched that problem but DemoStorage doesn't have that
limit :/)

I'm currently not sure what would be a good way:

- keeping everything as is and educate people about that limit in some
place where note() is documented
- have it implicitly reduce the note, but fail on large extended info
- cut back both, extended info and the note

I'm not feeling too good about cutting back a large extended info. Well.
Even on cutting back the note, as software or people might rely on them
to actually store what you give them or complain.

Cheers,
Christian

-- 
Christian Theune <ct at gocept.com>
gocept gmbh & co. kg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zodb-dev/attachments/20040901/649bc60b/attachment.bin