You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by "Pill, Juergen" <Ju...@softwareag.com> on 2001/02/21 13:18:26 UTC
RE: cvs commit: jakarta-slide/src/share/org/apache/slide/macro Ma
croImpl.java
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.
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?
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.
Best regards
Juergen Pill
-----Original Message-----
From: remm@apache.org [mailto:remm@apache.org]
Sent: Thursday, February 08, 2001 8:23 PM
To: jakarta-slide-cvs@apache.org
Subject: cvs commit: jakarta-slide/src/share/org/apache/slide/macro
MacroImpl.java
remm 01/02/08 11:22:46
Modified: src/share/org/apache/slide/macro MacroImpl.java
Log:
- Will not attempt to delete any revision. Only the struture will be
modified by
delete. This is the correct behavior IMO, because :
- If there is nothing in the structure, then the object is considered to
not exist.
- The object along with all its revisions can be resurrected by
recreating
it in the structure. This is very similar to CVS.
Revision Changes Path
1.8 +4 -14
jakarta-slide/src/share/org/apache/slide/macro/MacroImpl.java
Index: MacroImpl.java
===================================================================
RCS file:
/home/cvs/jakarta-slide/src/share/org/apache/slide/macro/MacroImpl.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- MacroImpl.java 2001/02/01 23:19:12 1.7
+++ MacroImpl.java 2001/02/08 19:22:32 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-slide/src/share/org/apache/slide/macro/MacroImpl.java,v
1.7 2001/02/01 23:19:12 remm Exp $
- * $Revision: 1.7 $
- * $Date: 2001/02/01 23:19:12 $
+ * $Header:
/home/cvs/jakarta-slide/src/share/org/apache/slide/macro/MacroImpl.java,v
1.8 2001/02/08 19:22:32 remm Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/02/08 19:22:32 $
*
* ====================================================================
*
@@ -76,7 +76,7 @@
* Macro helper class.
*
* @author <a href="mailto:remm@apache.org">Remy Maucherat</a>
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
public final class MacroImpl implements Macro {
@@ -414,16 +414,6 @@
deleteObject(token, (String) children.nextElement(),
e);
}
- }
-
- // Removing all revisions
- NodeRevisionDescriptors revisionDescriptors =
- contentHelper.retrieve(token, targetUri);
-
- // For now, only delete the initial revision
- if (revisionDescriptors.hasRevisions()) {
- contentHelper.remove(token, targetUri,
-
revisionDescriptors.getInitialRevision());
}
// Removing object
RE: cvs commit: jakarta-slide/src/share/org/apache/slide/macro Ma croImpl.java
Posted by Remy Maucherat <re...@betaversion.org>.
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