You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by "Roll, Kevin" <Ke...@idexx.com> on 2015/12/21 20:39:11 UTC
Dangling node_ids?
[I sent this to the Sling users list, but it may be more appropriate for this list]
I am attempting to determine why certain nodes in my repository have large data bundles, and I have uncovered another mystery. I wrote a simple servlet that accepts a UUID and returns the corresponding path. It just queries:
select * from [nt:base] where [jcr:uuid]=?
When I started plugging values in I discovered that a great many node_ids in DEFAULT_BUNDLE do not return a result for this query. In other words many rows in the DEFAULT_BUNDLE table do not appear to have a corresponding node or path in the repository.
Is this expected behavior or are these rows dangling? Can I safely delete them?
Thanks!
RE: Dangling node_ids?
Posted by "Roll, Kevin" <Ke...@idexx.com>.
That was my suspicion as to why I wasn't able to query certain nodes. I am able to access everything using the lower-level API, and so far everything looks great. Thanks for the info!
-----Original Message-----
From: Andrew Khoury [mailto:akhoury@adobe.com]
Sent: Monday, December 21, 2015 10:47 PM
To: <us...@jackrabbit.apache.org>
Subject: Re: Dangling node_ids?
Hi Kevin,
Based on my understanding, only nodes with mix:referenceable mixin are searchable via JCR SQL.
To get the path of all other nodes by uuid you can use Node.getByIdentifier http://www.day.com/specs/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html
This is all assuming as Clay said that the user of the JCR session has access to the node you are searching for.
Also, the reason for large bundles in a bundledbpersistencemanager could be large properties or a huge amount of direct child nodes. Each bundle serialization contains the node UUID, properties, parent node UUID, and child node names/uuids.
Thanks,
Andrew
> On Dec 21, 2015, at 6:47 PM, Clay Ferguson <wc...@gmail.com> wrote:
>
> I don't know what "DEFAULT_BUNDLE table" means, but I do know you shouldn't
> be looking directly at RDB tables in your backing store, right? Where are
> you getting he list of IDs ? Remember, nodes have privileges, and the
> session (user) that is running that query may not have ACL privileges to
> read the node you are failing to find.
>
> Best regards,
> Clay Ferguson
> wclayf@gmail.com
>
>
>> On Mon, Dec 21, 2015 at 1:39 PM, Roll, Kevin <Ke...@idexx.com> wrote:
>>
>> [I sent this to the Sling users list, but it may be more appropriate for
>> this list]
>>
>>
>>
>> I am attempting to determine why certain nodes in my repository have large
>> data bundles, and I have uncovered another mystery. I wrote a simple
>> servlet that accepts a UUID and returns the corresponding path. It just
>> queries:
>>
>>
>>
>> select * from [nt:base] where [jcr:uuid]=?
>>
>>
>>
>> When I started plugging values in I discovered that a great many node_ids
>> in DEFAULT_BUNDLE do not return a result for this query. In other words
>> many rows in the DEFAULT_BUNDLE table do not appear to have a corresponding
>> node or path in the repository.
>>
>>
>>
>> Is this expected behavior or are these rows dangling? Can I safely delete
>> them?
>>
>> Thanks!
>>
>>
Re: Dangling node_ids?
Posted by Clay Ferguson <wc...@gmail.com>.
Guys,
Here's an example of some searching, in my meta64 project.
https://github.com/Clay-Ferguson/meta64/blob/master/src/main/java/com/meta64/mobile/service/NodeSearchService.java
To me the key "power" is the ISDESCENDENTOF, because is lets you search
recursively under specific parts of the tree. In JCR_SQL2 i'm pretty sure
mix:referencable has nothing to do with whether you can search or not.
BTW, I'm converting meta64 to Polymer (WebComponents-based), because
JQueryMobile is dead. Polymer will be nearly identical in functionality but
just with better GUI.
Best regards,
Clay Ferguson
wclayf@gmail.com
On Mon, Dec 21, 2015 at 9:47 PM, Andrew Khoury <ak...@adobe.com> wrote:
> Hi Kevin,
> Based on my understanding, only nodes with mix:referenceable mixin are
> searchable via JCR SQL.
> To get the path of all other nodes by uuid you can use
> Node.getByIdentifier
> http://www.day.com/specs/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html
> This is all assuming as Clay said that the user of the JCR session has
> access to the node you are searching for.
> Also, the reason for large bundles in a bundledbpersistencemanager could
> be large properties or a huge amount of direct child nodes. Each bundle
> serialization contains the node UUID, properties, parent node UUID, and
> child node names/uuids.
> Thanks,
> Andrew
>
> > On Dec 21, 2015, at 6:47 PM, Clay Ferguson <wc...@gmail.com> wrote:
> >
> > I don't know what "DEFAULT_BUNDLE table" means, but I do know you
> shouldn't
> > be looking directly at RDB tables in your backing store, right? Where are
> > you getting he list of IDs ? Remember, nodes have privileges, and the
> > session (user) that is running that query may not have ACL privileges to
> > read the node you are failing to find.
> >
> > Best regards,
> > Clay Ferguson
> > wclayf@gmail.com
> >
> >
> >> On Mon, Dec 21, 2015 at 1:39 PM, Roll, Kevin <Ke...@idexx.com>
> wrote:
> >>
> >> [I sent this to the Sling users list, but it may be more appropriate for
> >> this list]
> >>
> >>
> >>
> >> I am attempting to determine why certain nodes in my repository have
> large
> >> data bundles, and I have uncovered another mystery. I wrote a simple
> >> servlet that accepts a UUID and returns the corresponding path. It just
> >> queries:
> >>
> >>
> >>
> >> select * from [nt:base] where [jcr:uuid]=?
> >>
> >>
> >>
> >> When I started plugging values in I discovered that a great many
> node_ids
> >> in DEFAULT_BUNDLE do not return a result for this query. In other words
> >> many rows in the DEFAULT_BUNDLE table do not appear to have a
> corresponding
> >> node or path in the repository.
> >>
> >>
> >>
> >> Is this expected behavior or are these rows dangling? Can I safely
> delete
> >> them?
> >>
> >> Thanks!
> >>
> >>
>
Re: Dangling node_ids?
Posted by Andrew Khoury <ak...@adobe.com>.
Hi Kevin,
Based on my understanding, only nodes with mix:referenceable mixin are searchable via JCR SQL.
To get the path of all other nodes by uuid you can use Node.getByIdentifier http://www.day.com/specs/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html
This is all assuming as Clay said that the user of the JCR session has access to the node you are searching for.
Also, the reason for large bundles in a bundledbpersistencemanager could be large properties or a huge amount of direct child nodes. Each bundle serialization contains the node UUID, properties, parent node UUID, and child node names/uuids.
Thanks,
Andrew
> On Dec 21, 2015, at 6:47 PM, Clay Ferguson <wc...@gmail.com> wrote:
>
> I don't know what "DEFAULT_BUNDLE table" means, but I do know you shouldn't
> be looking directly at RDB tables in your backing store, right? Where are
> you getting he list of IDs ? Remember, nodes have privileges, and the
> session (user) that is running that query may not have ACL privileges to
> read the node you are failing to find.
>
> Best regards,
> Clay Ferguson
> wclayf@gmail.com
>
>
>> On Mon, Dec 21, 2015 at 1:39 PM, Roll, Kevin <Ke...@idexx.com> wrote:
>>
>> [I sent this to the Sling users list, but it may be more appropriate for
>> this list]
>>
>>
>>
>> I am attempting to determine why certain nodes in my repository have large
>> data bundles, and I have uncovered another mystery. I wrote a simple
>> servlet that accepts a UUID and returns the corresponding path. It just
>> queries:
>>
>>
>>
>> select * from [nt:base] where [jcr:uuid]=?
>>
>>
>>
>> When I started plugging values in I discovered that a great many node_ids
>> in DEFAULT_BUNDLE do not return a result for this query. In other words
>> many rows in the DEFAULT_BUNDLE table do not appear to have a corresponding
>> node or path in the repository.
>>
>>
>>
>> Is this expected behavior or are these rows dangling? Can I safely delete
>> them?
>>
>> Thanks!
>>
>>
Re: Dangling node_ids?
Posted by Clay Ferguson <wc...@gmail.com>.
I don't know what "DEFAULT_BUNDLE table" means, but I do know you shouldn't
be looking directly at RDB tables in your backing store, right? Where are
you getting he list of IDs ? Remember, nodes have privileges, and the
session (user) that is running that query may not have ACL privileges to
read the node you are failing to find.
Best regards,
Clay Ferguson
wclayf@gmail.com
On Mon, Dec 21, 2015 at 1:39 PM, Roll, Kevin <Ke...@idexx.com> wrote:
> [I sent this to the Sling users list, but it may be more appropriate for
> this list]
>
>
>
> I am attempting to determine why certain nodes in my repository have large
> data bundles, and I have uncovered another mystery. I wrote a simple
> servlet that accepts a UUID and returns the corresponding path. It just
> queries:
>
>
>
> select * from [nt:base] where [jcr:uuid]=?
>
>
>
> When I started plugging values in I discovered that a great many node_ids
> in DEFAULT_BUNDLE do not return a result for this query. In other words
> many rows in the DEFAULT_BUNDLE table do not appear to have a corresponding
> node or path in the repository.
>
>
>
> Is this expected behavior or are these rows dangling? Can I safely delete
> them?
>
> Thanks!
>
>