[lxml-dev] LXML and persistence with the ZODB?

[Stefan Behnel]

Hi,

Martijn Faassen wrote:
> On Fri, Jun 27, 2008 at 8:32 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Martijn Faassen wrote:
>>> That said, it'd still be tricky. It'd be nice to get a modification
>>> notification from lxml for instance, so that the ZODB knows that a tree
>>> has been changed and thus needs to be marked dirty so that a new
>>> transaction can be committed.
>> If someone provides code for such a feature, I will consider adding it.
>> However, it must have a negligible performance impact (especially if not used)
>> and meaningful event types.
> 
> What do you mean by meaningful event types? There's only one relevant
> event in case of the ZODB: the tree has changed.

What is a tree? Imagine you have two ElementTree objects wrapping subtrees one
of which is contained in the other. Now a subtree of both changes. What
event(s) do you expect?

And is "tree changed" really enough, or are there applications that can
benefit from a distinction between creation, update and removal of Elements?

What information is part of an event notification? Should applications be able
to efficiently decide if it affects a certain subtree before they react or not?

What about just changing the text of an Element? Should the Element create an
event or is this also only a tree event?


>> Problems: the public C-API enables access to the tree at the C level, and
>> adding an Element to a different tree removes it from the source tree, so
>> changes can be non-local for a tree.
> 
> I think we may be able to ignore the C-API, and just tell people who
> really want to make sure this works to also manually call invalidate.

I'm fine with that.


> When an element is added to a different tree I think you still have
> enough time to mark the original tree dirty though, right?

Sure, but these things usually involve more issues than you can see before you
start implementing them. I have no idea if this has any impact on the source
thread of a tree, for example.


>> I wonder if it isn't enough to put a warning into the docs that pickling does
>> not store all tree state and that unpickling will only work correctly inside
>> the same parser setup that was used for pickling. I would expect that most
>> applications can easily achieve this.
>>
>> We'd only have to find a way to associate a concrete parser setup with an
>> unpickler.
> 
> Tricky.. In the case of the ZODB, we don't control pickling or
> unpickling directly, or when it happens, and you'd still want to
> support the case of different parser setups in different cases.

Definitely. It's just easier in objectify because there is a comprehensive
default setup, so most people won't notice that pickling is not parser-specific.

Stefan