Quoting "Pill, Juergen" <[EMAIL PROTECTED]>:
> Hello Remy,
>
> I just found out one implication of not deleting the revisions:
>
> If only the structure is deleted, the child store "content" is not
> informed
> about the delete. Therefore the content object persists, but the
> logical
> part (node) is removed. If the object is re-created the content object
> is
> located twice in the persistent store.
I don't understand what's happening here.
If the object is not versioned the content should be overwritten.
> If the resource is not revisioned, I believe it would be OK to remove
> it
> completely. This keeps the persistent store smaller. Possibly we could
> have
> a flag (in domain.xml?) to specify if the delete is persistent, or the
> content can be recreated.
> If the resource is revisioned, I believe we should have two methods to
> delete. One deletes the revision permanently, the other deletes it
> logically
> only. I have not read the Delta-V standard in detail, does someone know
> if
> this behavior is part of the standard.
>
> What do you think?
So we should go for this :
a) If the object is versioned, do a fake delete (only delete the structure).
b) If the object is not versioned (which is the case for all objects created
through the current WebDAV servlet), do a real delete.
That's what would happen with Delta V, unless I misunderstood something, since
individual revisions of an object are resources located somewhere else.
Deleting the versioned resource (which holds a directory of the revision
resources) wouldn't affect them.
> PS. Lately I was searching for following problem: create, lock, delete,
> create a resource. If the resource was locked again an error message
> was
> produced, resource already locked. I believe now, this has something to
> do
> with deleting the nodes only.
I really don't know what to do about that, actually. What happens here is that
the lock survives the delete, and later when you try to acquire a new lock,
Slide returns a locked status because you attempt to lock twice the object.
It is very unclear in teh WebDAV spec whether or not a lock will survive a
delete. You're allowed to lock a non-existing resource, and it creates a lock-
null resource. When you delete a locked resource, does it go back to a lock-
null state ? This would be quite painful to implement, and would cause problems
for recursive delete (the parent collection of the lock-null resource couldn't
be deleted until you unlock the resource).
So I would say we should remove the lock when we delete a resource (but that's
more because implementing the other behavior would be much harder).
Remy
