RE: cvs commit: jakarta-slide/src/share/org/apache/slide/macro Ma croImpl.java

["Pill, Juergen" <Ju...@softwareag.com>]

Hi Remy,

yes, I think too we should delete in the non-versioned case all the elements
in the various child stores (lock, security, content, RD, RDS). This would
solve the lock problem for the unversioned case too, isn't it?

Do you want to do the necessary changes?

Best regards

Juergen



-----Original Message-----
From: Remy Maucherat [mailto:remy@betaversion.org]
Sent: Wednesday, February 21, 2001 10:57 PM
To: slide-dev@jakarta.apache.org
Subject: RE: cvs commit: jakarta-slide/src/share/org/apache/slide/macro
Ma croImpl.java


Quoting "Pill, Juergen" <Ju...@softwareag.com>:

> 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

Re: cvs commit: jakarta-slide/src/share/org/apache/slide/macro Ma croImpl.java

[Remy Maucherat <re...@apache.org>]

> Hi Remy,
>
> yes, I think too we should delete in the non-versioned case all the
elements
> in the various child stores (lock, security, content, RD, RDS). This would
> solve the lock problem for the unversioned case too, isn't it?
>
> Do you want to do the necessary changes?

I have a lot of other items on my todo list, so if you had time to do it,
that would be great.

Remy