>> Since the support for final deletion of a node is not in there (yet) >What do you mean by this? Cédric wrote a few days ago: >As of 1.6, empty and unused VersionHistory will be automatically removed >after removal of the last Version (see >https://issues.apache.org/jira/browse/JCR-134). >This will ensure that the disk usage will not grow unnecessarily. As the lead developer of another rather large open source project I always like to think it's more constructive to work with the possibilities, rather than the impossibilities. With that attitude it still makes sense to have a debate on whether or not Jackrabbit acts according to the JCR-specs, but it wouldn't block you from creating a solution that works. Cheers, Matt Matt Casters Chief Data Integration Pentaho : The Commercial Open Source Alternative for Business Intelligence
On Monday 20 July 2009 14:33:34 Wulf Rowek | THESISdigital wrote: > Hi Matt, > > thanks for your detailed answer. > My intention for deleting nodes is, that i don't want to deal with them > after removing. You always have to check on your "deleted"-flag, either > on node- or querylevel. > > For the moment i implemented a workaround like you suggested, only that > i use something like a trash where i just move my node, i like to delete. > > But still, I think this is nothing more like a workaround and should > achieved with node.remove and and workspace.restore or something similar > and not with session.move or node.hasProperty > > > Since the support for final deletion of a node is not in there (yet) > What do you mean by this? > > Do you mean that the JCR-Specs doesn't define the removing of the > version history at all and instead only the removing of partial versions? > > regards, > > wulf > > > > [email protected] schrieb: > > Since the support for final deletion of a node is not in there (yet), why > > would you even try to delete it? > > The way I solved is with a simple "deleted" property on the nodes. > > I then simply ignore nodes where this property is set to true (in my > > application). > > Restoring is then simply a matter or setting the property back to false. > > You can then either create a bin or allow certain users to view/restore > > deleted items. > > > > When permanent deletion of nodes arrives (1.6/2.0?) I'll create an > > administration option to purge deleted object permanently. > > > > Cheers, > > Matt > > > > Matt Casters > > Chief Data Integration > > Pentaho : The Commercial Open Source Alternative for Business Intelligence > > > > > > > > On Monday 20 July 2009 13:58:32 Wulf Rowek | THESISdigital wrote: > >> Hi, > >> > >> i've asked this already in another thread, but I think it is better to > >> open an own one. > >> > >> It looks like it is not the intention of the version system (at least in > >> the the meaning of jcr-170), but maybe (hopefully) i'm wrong: > >> > >> is it possible to restore a deleted versioned node? I cannot understand > >> why it should not, because all information (except the former path) is > >> contained in the version history. > >> Is there any simple method like workspace.restore(String uuid, String > >> pathToRestoreNode)? > >> > >> I will appreciate any comment to this. > >> > >> regards, > >> > >> Wulf > >> > > > > > >
