jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pkrishna <prabhakar.krishnasw...@ge.com>
Subject Re: Technical Issue related to Versioning
Date Mon, 15 Dec 2008 15:43:40 GMT

well, the reason I was using the '<' was to find a version less than the
current version. Anyway, I wanted to say the browsing code works fine. I
realized after I posted this on the forum. What I now realize is that when
an item is saved the first time, no version is created in the version
history. My belief is that versions starting with 1.0 gets created after an
initial checkout\checkin sequence.


pkrishna wrote:
> 
> I have browsed through versioning issues in the forum and not able to get
> the answer I want. Here is the structure of the nodes we have:
> 
> level 1 -- Nodes in this level are not versionable (can have more than one
> node at this level) -- custom node type
> level 2 -- Nodes at this level are versionable (child of level 1, many
> nodes allowed ) -- custom node type
> level 3 -- jcr:content Node (child of level 2)
> 
> I am trying to find a specific version of level 2 and not being able to
> find a way to do it.
> 
> Initially I used the following XPATH query based on discussions in the
> forum:
> 
> 
>  String query = "//element(*,nt:frozenNode)[@ecr:version=" + "'" + version
> + "'"
>                     + " and jcr:frozenUuid <" + "'" + variant.getUUID() +
> "']";
> when this query is executed, I do get all the versionable nodes but it
> does not tell me if that is node I am after.
> 
> Example:
> 
> Let A and B be  level one nodes
> Let C and D be level two nodes
> 
> I have versions of both C and D. If I run the above query, I may get the
> previous versions of both C and D since both may match the criteria of
> having a frozenUuid < than the node UUID and have the same version. I
> tried to match on the name of the parent of the frozen Nodes returned but
> they don't match the names in 'default' workspace. The level 1 nodes have
> a unique name in the default workspace but quickly I found the parent name
> of level 2 node does not match the parent name in version storage.
> 
> Then I tried a different approach. I read in an article that it is
> possible to browse the version history of a particular node. So I used the
> following snippet of code:
> 
>  VersionHistory vh = node.getVersionHistory();            
>  VersionIterator vi = vh.getAllVersions();         
>  vi.skip(1); // this is the root
>           while (vi.hasNext()) {
>                
> System.out.println("-----------------------------------------");
>                 Version v = vi.nextVersion();
>                 NodeIterator ni = v.getNodes();
>                 while (ni.hasNext()) {
> 
>                     Node nv = ni.nextNode();
>                     Property p = nv.getProperty("ecr:version");
>                     long val = p.getLong();
>                     System.out.println("Version: " + val);
>                     if (val == version.longValue()) { // interested in
> matching the version
>                         return nv;
>                     }
>                 }
> 
>             }
> 
> The above code execute the version loop ony once and this version reflects
> the current version. I expected the loop to execute atleast twice since I
> have a version 1 and version 2 and I was looking for version 1 but
> couldn't find it.
> 
> Is there a way to find the version I am looking for? am I missing
> something?
> 
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Technical-Issue-related-to-Versioning-tp20984376p21016120.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Mime
View raw message