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 <[email protected]> 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 > [email protected] > > >> On Mon, Dec 21, 2015 at 1:39 PM, Roll, Kevin <[email protected]> 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! >> >>
