Could you further explain your suggestion? If you refer to my original email, I'm already making each child node versionable. So when you say, "only when you change it", does that mean changing the onParentVersion property to ABORT/IGNORE?
On Wed, Jan 21, 2009 at 11:00 PM, Diego Marin Santos <[email protected]> wrote: > My suggestion is that you make versionable each child node and only when you > change it. If you want to return to a previous state, simply remove the > child node that you want (if it was not modified) or restore a previous > version(if it was modified). > > > 2009/1/21 Alexander Klimetschek <[email protected]> > >> On Wed, Jan 21, 2009 at 8:21 PM, Micah Whitacre <[email protected]> >> wrote: >> > Hmm that clarifies and explains what I am seeing and why I am seeing >> > that behavior. However I'm assuming if I were to alter that property >> > (to what value I'm not sure) I would lose the ability to retrieve the >> > child nodes at the time the version was created from the frozen node? >> > So code like this would no longer work: >> > >> > Version version = node.getBaseVersion(); >> > Node versionNode = version.getNode("jcr:frozenNode"); >> > NodeIterator it = node.getNodes(); >> > //it would contain all my child nodes. >> > >> > Wouldn't that negate the benefit of having versioned nodes if I >> > couldn't retrieve the state of the repository for a certain version? >> >> I guess that Jackrabbit's versioning isn't optimized for that use case >> yet. Most versioning use cases are on a per node incl. all child nodes >> basis, ie. the whole subtree is versioned once upon a checkin, while >> the structure above that node is not versioned. This is typical for a >> CMS scenario, where you do not version the structure of your site, but >> version individual pages. In your case, however, the main point is in >> versioning the rather large structure of child nodes. >> >> BTW, I am wondering why you first do a node.checkin() and then >> child.checkin() in the code you've posted. Shouldn't it be the other >> way around? >> >> Regards, >> Alex >> >> -- >> Alexander Klimetschek >> [email protected] >> >
