I tried but I couldn't find a way to avoid having two joins with your use case. My question is that are you experiencing inefficiency or you're assuming it's inefficient? In my LIMITED experience JCR SQL2 can be pretty verbose, but I'm not so sure the verboseness is has a direct correlation with the efficiency of a query.
Sorry, I'm not sure how XPath is parsed vs SQL2, hopefully someone else can shed light on that. -----Original Message----- From: Stephen Byrne [mailto:[email protected]] Sent: Thursday, August 11, 2011 9:13 AM To: [email protected] Subject: Efficiency of query matching child's property I am writing a query that selects nodes based on their children's property values. The node I want to select looks like this (among many others nodes with the same structure but different property values): /myItem (sb:item) .a (sb:itemChild) ..@sb:value = "one" .b (sb:itemChild) ..@sb:value = "two" .c (sb:itemChild) ..@sb:value = "three" XPath: //element(*,sb:item)[a/sb:value="one" and b/sb:value="two"] If using SQL2 or QOM it seems I have to separate some of the join conditions to the where clause, which has got to be pretty inefficient: SELECT * FROM [sb:item] AS [item] INNER JOIN [sb:itemChild] AS [childA] ON ISCHILDNODE( [childA], [item] ) INNER JOIN [sb:itemChild] AS [childB] ON ISCHILDNODE( [childB], [item] ) WHERE NAME([childA]) = "a" // logically part of first join AND [childA].[sb:value] = "one" // logically part of the first join AND NAME([childB]) = "b" // logically part of second join AND [childB].[sb:value] = "two" // logically part of the second join I realize in this simple case a, b, and c could be properties of myItem, which would drastically simply and speed up the query. My actual model has more complex subtrees for a, b, and c. Is there a way to have multiple conditions for a join and I just missed it? Is XPath parsed to a similar QOM tree? -- Stephen Byrne LincWare, LLC [email protected]
