Comment 11 for bug 240381

On Fri, Nov 20, 2009 at 2:49 PM, Christian Theune <email address hidden> wrote:
> Actually this is interesting on the ZODB level. With current discussion
> about high quality backup strategies on the ZODB development list and
> the pointer back to this bug I found a solution how this might be solved
> easily on the ZODB level.
>
> The underlying issue here is that blobs use the OID as the pointer to
> which file belongs to it.

All objects use the oid as a key to where the data are.

> When copying a blob object that piece of data
> goes away.

Also when copying a regular object.

> IMHO the ZODB kinda nurishes the assumption that the content
> of an object is what is stored in the pickle, so as a consequence if I
> pickle/unpickle such an object its value should be the same.

If you buy the premise, which I don't. Copying objects is always tricky
and somewhat application dependent.

> Thus th idea of a solution: we could save the OID in the state of the
> blob object and if that is different from the _p_oid then we know we
> need to initialise the blob from that object's state, e.g. by providing
> a new hard link to that file.
>
> Maybe we don't even have to store that marker in the object's value
> persistently, but I don't know, we'll see.

You haven't fleshed this out enough for me to judge this. You also
haven't really defined copying for that matter. There are many ways to
copy an object and it's not clear what's meant in the context of ZODB,
which is why I view this as an application issue, rather than a ZODB issue.

Perhaps you should come up with some definition of copying in the context of
ZODB and then we can decide if there is a compelling reason to
have such a feature in ZODB.

Given other priorities, I don't think we should try to deal with this.

Jim

--
Jim Fulton