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 [email protected] On Mon, Dec 21, 2015 at 9:47 PM, Andrew Khoury <[email protected]> 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 <[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! > >> > >> >
