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

[Martijn Faassen]

Hey,

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.

> 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.
When an element is added to a different tree I think you still have
enough time to mark the original tree dirty though, right?

> 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.

Not that I'm in urgent need of this feature, but it'd be very cool if
it worked nonetheless, it opens up some interesting possibilities.

Regards,

Martijn