Delete References Problem

[Nick Stuart-3]

I dont know if this is really an issue or not, but reading the API and the
current behavior I think something is mixed.

Fairly simple use case. I have a nt:linkedFile somewhere, and I try to
delete the original file (or nt:folder containing the file) and i get
a ReferentialIntegrityException. Looking at the JCR API ofr Item.remove() it
says it will only through this exception if I have READONLY access to the
item AND the item is outside the subtree. In my case the Item is outside the
subtree, but I believe I have read/write access to the linked item.

Is there a 'good' way to accomplish what I want? I'm thinking I have to loop
through all the sub nt:folders and files and get their REFERENCE properties
and remove those. Kind of a pain, but not horrible. Is there a way to do
this automatically?

The full exception I am getting is this:

Caused by: javax.jcr.ReferentialIntegrityException:
05ad7f33-336a-40b0-bc19-8ded288c89b6: the node cannot be removed because it
is still being referenced.
  at
org.apache.jackrabbit.core.state.SharedItemStateManager.checkReferentialIntegrity(SharedItemStateManager.java:1431)
  at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:565)
  at
org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:852)
  at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:882)
  at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:334)
  at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:337)
  at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:310)
  at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:313)
  at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1102)
  at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:839)

Thanks for the help and any extra info!

-Nick

[Tobias Bocanegra]

use:  Node.getReferences() to find are properties that refer to this file.

regards, toby

On 7/3/08, Nick Stuart <nstuart@...> wrote:

> I dont know if this is really an issue or not, but reading the API and the
>  current behavior I think something is mixed.
>
>  Fairly simple use case. I have a nt:linkedFile somewhere, and I try to
>  delete the original file (or nt:folder containing the file) and i get
>  a ReferentialIntegrityException. Looking at the JCR API ofr Item.remove() it
>  says it will only through this exception if I have READONLY access to the
>  item AND the item is outside the subtree. In my case the Item is outside the
>  subtree, but I believe I have read/write access to the linked item.
>
>  Is there a 'good' way to accomplish what I want? I'm thinking I have to loop
>  through all the sub nt:folders and files and get their REFERENCE properties
>  and remove those. Kind of a pain, but not horrible. Is there a way to do
>  this automatically?
>
>  The full exception I am getting is this:
>
>  Caused by: javax.jcr.ReferentialIntegrityException:
>  05ad7f33-336a-40b0-bc19-8ded288c89b6: the node cannot be removed because it
>  is still being referenced.
>   at
>  org.apache.jackrabbit.core.state.SharedItemStateManager.checkReferentialIntegrity(SharedItemStateManager.java:1431)
>   at
>  org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:565)
>   at
>  org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:852)
>   at
>  org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:882)
>   at
>  org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:334)
>   at
>  org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:337)
>   at
>  org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:310)
>   at
>  org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:313)
>   at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1102)
>   at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:839)
>
>  Thanks for the help and any extra info!
>
>
>  -Nick
>

[Nick Stuart-3]

Right, that I know, but thats not really my question. The JCR API reads as:

"A ReferentialIntegrityException will be thrown on save if this item or an
item in its subtree is currently the target of a REFERENCE property located
in this workspace but outside this item's subtree and the current Session
has read access to that REFERENCE property."

So I have a reference that is outside the item's subtree BUT I have
read/write access to it so I should be able to just call remove() on that
folder.

Anyways, I was able to write a simple method to delete all references, just
a little annoyance is all.

-Nick

On 7/3/08, Tobias Bocanegra <tobias.bocanegra@...> wrote:

>
> use:  Node.getReferences() to find are properties that refer to this file.
>
> regards, toby
>
>
> On 7/3/08, Nick Stuart <nstuart@...> wrote:
> > I dont know if this is really an issue or not, but reading the API and
> the
> >  current behavior I think something is mixed.
> >
> >  Fairly simple use case. I have a nt:linkedFile somewhere, and I try to
> >  delete the original file (or nt:folder containing the file) and i get
> >  a ReferentialIntegrityException. Looking at the JCR API ofr
> Item.remove() it
> >  says it will only through this exception if I have READONLY access to
> the
> >  item AND the item is outside the subtree. In my case the Item is outside
> the
> >  subtree, but I believe I have read/write access to the linked item.
> >
> >  Is there a 'good' way to accomplish what I want? I'm thinking I have to
> loop
> >  through all the sub nt:folders and files and get their REFERENCE
> properties
> >  and remove those. Kind of a pain, but not horrible. Is there a way to do
> >  this automatically?
> >
> >  The full exception I am getting is this:
> >
> >  Caused by: javax.jcr.ReferentialIntegrityException:
> >  05ad7f33-336a-40b0-bc19-8ded288c89b6: the node cannot be removed because
> it
> >  is still being referenced.
> >   at
>
> >  org.apache.jackrabbit.core.state.SharedItemStateManager.checkReferentialIntegrity(SharedItemStateManager.java:1431)
> >   at
>
> >  org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:565)
> >   at
>
> >  org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:852)
> >   at
>
> >  org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:882)
> >   at
>
> >  org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:334)
> >   at
>
> >  org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:337)
> >   at
>
> >  org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:310)
> >   at
>
> >  org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:313)
> >   at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1102)
> >   at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:839)
> >
> >  Thanks for the help and any extra info!
> >
> >
> >  -Nick
> >
>

[Tobias Bocanegra]

On 7/3/08, Nick Stuart <nstuart@...> wrote:

> Right, that I know, but thats not really my question. The JCR API reads as:
>
>  "A ReferentialIntegrityException will be thrown on save if this item or an
>  item in its subtree is currently the target of a REFERENCE property located
>  in this workspace but outside this item's subtree and the current Session
>  has read access to that REFERENCE property."
>
>  So I have a reference that is outside the item's subtree BUT I have
>  read/write access to it so I should be able to just call remove() on that
>  folder.

i think the above means, that it throws a ref-exception and not a
accessdenied. but as long as the node is referenced it never can be
deleted, irrespective of the access rights.

>  Anyways, I was able to write a simple method to delete all references, just
>  a little annoyance is all.
it's no more than:
for (PropertyIterator iter = node.getReferences(); iter.hasNext();
iter.nextProperty().remove());

right?

regards, toby

>
>
>  -Nick
>
>
>  On 7/3/08, Tobias Bocanegra <tobias.bocanegra@...> wrote:
>  >
>  > use:  Node.getReferences() to find are properties that refer to this file.
>  >
>  > regards, toby
>  >
>  >
>  > On 7/3/08, Nick Stuart <nstuart@...> wrote:
>  > > I dont know if this is really an issue or not, but reading the API and
>  > the
>  > >  current behavior I think something is mixed.
>  > >
>  > >  Fairly simple use case. I have a nt:linkedFile somewhere, and I try to
>  > >  delete the original file (or nt:folder containing the file) and i get
>  > >  a ReferentialIntegrityException. Looking at the JCR API ofr
>  > Item.remove() it
>  > >  says it will only through this exception if I have READONLY access to
>  > the
>  > >  item AND the item is outside the subtree. In my case the Item is outside
>  > the
>  > >  subtree, but I believe I have read/write access to the linked item.
>  > >
>  > >  Is there a 'good' way to accomplish what I want? I'm thinking I have to
>  > loop
>  > >  through all the sub nt:folders and files and get their REFERENCE
>  > properties
>  > >  and remove those. Kind of a pain, but not horrible. Is there a way to do
>  > >  this automatically?
>  > >
>  > >  The full exception I am getting is this:
>  > >
>  > >  Caused by: javax.jcr.ReferentialIntegrityException:
>  > >  05ad7f33-336a-40b0-bc19-8ded288c89b6: the node cannot be removed because
>  > it
>  > >  is still being referenced.
>  > >   at
>  >
>  > >  org.apache.jackrabbit.core.state.SharedItemStateManager.checkReferentialIntegrity(SharedItemStateManager.java:1431)
>  > >   at
>  >
>  > >  org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:565)
>  > >   at
>  >
>  > >  org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:852)
>  > >   at
>  >
>  > >  org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:882)
>  > >   at
>  >
>  > >  org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:334)
>  > >   at
>  >
>  > >  org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:337)
>  > >   at
>  >
>  > >  org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:310)
>  > >   at
>  >
>  > >  org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:313)
>  > >   at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1102)
>  > >   at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:839)
>  > >
>  > >  Thanks for the help and any extra info!
>  > >
>  > >
>  > >  -Nick
>  > >
>  >
>

[Nick Stuart-3]

Alright, well it mostly just comes down to a wording issue, so no big deal.

And its very similar to that loop Tobias, but I actually remove the parent
node, because if just the property is removed it complains when you save the
session because now you have a linkedFile type with out the required
property. (important note to remove the getParent() node, and not the
getNode() node, as getNode() returns the 'original' node that the link is
pointing to...just noting for future searchs/inquiries)

-Nick

On 7/3/08, Tobias Bocanegra <tobias.bocanegra@...> wrote:

>
> On 7/3/08, Nick Stuart <nstuart@...> wrote:
>
> > Right, that I know, but thats not really my question. The JCR API reads
> as:
> >
> >  "A ReferentialIntegrityException will be thrown on save if this item or
> an
> >  item in its subtree is currently the target of a REFERENCE property
> located
> >  in this workspace but outside this item's subtree and the current
> Session
> >  has read access to that REFERENCE property."
> >
> >  So I have a reference that is outside the item's subtree BUT I have
> >  read/write access to it so I should be able to just call remove() on
> that
> >  folder.
>
> i think the above means, that it throws a ref-exception and not a
> accessdenied. but as long as the node is referenced it never can be
> deleted, irrespective of the access rights.
>
>
> >  Anyways, I was able to write a simple method to delete all references,
> just
> >  a little annoyance is all.
>
> it's no more than:
> for (PropertyIterator iter = node.getReferences(); iter.hasNext();
> iter.nextProperty().remove());
>
> right?
>
> regards, toby
>
> >
> >
> >  -Nick
> >
> >
> >  On 7/3/08, Tobias Bocanegra <tobias.bocanegra@...> wrote:
> >  >
> >  > use:  Node.getReferences() to find are properties that refer to this
> file.
> >  >
> >  > regards, toby
> >  >
> >  >
> >  > On 7/3/08, Nick Stuart <nstuart@...> wrote:
> >  > > I dont know if this is really an issue or not, but reading the API
> and
> >  > the
> >  > >  current behavior I think something is mixed.
> >  > >
> >  > >  Fairly simple use case. I have a nt:linkedFile somewhere, and I try
> to
> >  > >  delete the original file (or nt:folder containing the file) and i
> get
> >  > >  a ReferentialIntegrityException. Looking at the JCR API ofr
> >  > Item.remove() it
> >  > >  says it will only through this exception if I have READONLY access
> to
> >  > the
> >  > >  item AND the item is outside the subtree. In my case the Item is
> outside
> >  > the
> >  > >  subtree, but I believe I have read/write access to the linked item.
> >  > >
> >  > >  Is there a 'good' way to accomplish what I want? I'm thinking I
> have to
> >  > loop
> >  > >  through all the sub nt:folders and files and get their REFERENCE
> >  > properties
> >  > >  and remove those. Kind of a pain, but not horrible. Is there a way
> to do
> >  > >  this automatically?
> >  > >
> >  > >  The full exception I am getting is this:
> >  > >
> >  > >  Caused by: javax.jcr.ReferentialIntegrityException:
> >  > >  05ad7f33-336a-40b0-bc19-8ded288c89b6: the node cannot be removed
> because
> >  > it
> >  > >  is still being referenced.
> >  > >   at
> >  >
> >  >
> >  org.apache.jackrabbit.core.state.SharedItemStateManager.checkReferentialIntegrity(SharedItemStateManager.java:1431)
> >  > >   at
> >  >
> >  >
> >  org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:565)
> >  > >   at
> >  >
> >  >
> >  org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:852)
> >  > >   at
> >  >
> >  >
> >  org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:882)
> >  > >   at
> >  >
> >  >
> >  org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:334)
> >  > >   at
> >  >
> >  >
> >  org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:337)
> >  > >   at
> >  >
> >  >
> >  org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:310)
> >  > >   at
> >  >
> >  >
> >  org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:313)
> >  > >   at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1102)
> >  > >   at
> org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:839)
> >  > >
> >  > >  Thanks for the help and any extra info!
> >  > >
> >  > >
> >  > >  -Nick
> >  > >
> >  >
> >
>