8 Replies Latest reply on Jan 10, 2012 6:59 PM by rhauch

    Path Query syntax


      Happy New Year Modeshapers,


      I was using a SQL2 query string like this one:


      SELECT * FROM [nt:unstructured] AS node WHERE ISDESCENDANTNODE(asset, [" + path + "]) AND (LOCALNAME(node) = 'name')


      where path is the path of a node obtained by the Node.getPath() method.


      This works fine only if the path does not contains ']' character which happens when you have same name sibling.


      I have tried this then:


      SELECT * FROM [nt:unstructured] AS node WHERE ISDESCENDANTNODE(asset, [\"" + path + "\"]) AND (LOCALNAME(node) = 'name')


      that is adding double quotes around path. But this does not work either.


      Finally I have tried this:


      SELECT * FROM [nt:unstructured] AS node WHERE ISDESCENDANTNODE(asset, \"[" + path + "]\") AND (LOCALNAME(node) = 'name')


      that is adding double quote before and after the '[' and ']' character. And this works.


      Still I do feel that either the first or second query strings should have worked.



        • 1. Re: Path Query syntax

          Perhaps you could post an example of a SQL2 query string expression, without the Java concatenation operator and showing a value for the path. I guess I'm confused by the square brackets, which signal an identifier path rather than a more typical path composed of multiple name segments.

          • 2. Re: Path Query syntax

            Not sure about your comment about the square brackets, at least this is not how I read it in the JCR spec.

            Anyway here is an edited example (by 'edited' I mean that I have replaced actual values with the dummy characters 'x')


            SELECT * FROM [nt:unstructured] AS xxxxx WHERE ISDESCENDANTNODE(xxxxx, [/xxxxxxx/xxxxxxxxx/xx/xxx:xxxxx/xxxxxx[3]]) AND (LOCALNAME(xxxxx) = 'name')


            the error was:


            is not well-formed: Expecting ')' but found ']' at line 1, column 114: /xxx:xxxxx/xxxxxxx[3] ===>> ]) AND (LOCALNAME(node


            and the reason is that the parser when it finds a '[' character will get all the characters until it found a closing ']' character.

            So in this case it stops at the one after '3'. The next expected character is a ')' but in my case this is a ']'

            • 3. Re: Path Query syntax

              Sorry, I misunderstood the square brackets as being part of the path literal, rather than being the quote characters around the path.


              There is a bug when the path contains same-name-siblings. Honestly, I can't believe the JSR-283 actually chose to use the same characters to quote the path literal that are commonly used within the path. So we're losing the context for the closing square brackets. IOW, this works:


              SELECT * FROM [car:Car] WHERE ISDESCENDANTNODE([car:Car],[/foo/bar])


              but this does not (and should):


              SELECT * FROM [car:Car] WHERE ISDESCENDANTNODE([car:Car],[/foo/bar[2]])


              I've logged this as MODE-1366.


              IMO the best workaround is to quote the path literal with single quotes or double quotes (instead of using square brackets). For example, these all work in ModeShape:


              SELECT * FROM [car:Car] WHERE ISDESCENDANTNODE([car:Car],'/foo/bar')

              SELECT * FROM [car:Car] WHERE ISDESCENDANTNODE([car:Car],'/foo/bar[2]')

              SELECT * FROM [car:Car] WHERE ISDESCENDANTNODE([car:Car],"/foo/bar")

              SELECT * FROM [car:Car] WHERE ISDESCENDANTNODE([car:Car],"/foo/bar[2]")


              Incidentally, in ModeShape you can also use the single or double quotes to surround any identifier (like you can in most SQL dialects):


              SELECT * FROM 'car:Car' WHERE ISDESCENDANTNODE('car:Car','/foo/bar')

              SELECT * FROM 'car:Car' WHERE ISDESCENDANTNODE('car:Car','/foo/bar[2]')

              SELECT * FROM 'car:Car' WHERE ISDESCENDANTNODE("car:Car","/foo/bar")

              SELECT * FROM "car:Car" WHERE ISDESCENDANTNODE("car:Car","/foo/bar[2]")


              Just be sure to not mix single and double quote characters around a single identifier.

              • 4. Re: Path Query syntax

                Thank you Randall.


                Frankly I was using the brackets because the spec reads like:


                Path ::= '[' quotedPath ']' |
                             '[' simplePath ']' |


                and I am not sure what a 'simplePath' versus a 'quotedPath' was.



                • 5. Re: Path Query syntax

                  A simplePath may be quoted, but doesn't need to be. I think the notion of "simple" and "quoted" is more useful with names (see Section 6.7.4). After all, almost all paths will contain the '/' character, which is not a valid SQL-99 character - therefore, practically speaking most paths will always need to be quoted.


                  Anyway, thanks for reporting the problem.

                  • 6. Re: Path Query syntax

                    While I have your attention, this is a totally unrelated question.

                    I have read why you wrote about Modeshape 3.0 which looks very promising.

                    I did not find though anything related to the Lucene indexing (which if you remember was one of my concern when deleting a node).

                    So my question is: will modeshape 3 use the same logic ?

                    And also the same old pesky question: any ETA ?

                    • 7. Re: Path Query syntax

                      ModeShape 3 will also use Lucene, but we're completely overhauling (and simplifying) the code that updates the indexes, including the code that removes the records from the indexes upon a delete (which should be significantly faster than with 2.x). I'm working on the indexing code now.


                      We hope to release a couple of alphas (starting next week), a couple of betas, and the final release before the end of Feb. That's our goal, anyway.

                      • 8. Re: Path Query syntax

                        MODE-1366 has been fixed and will be in the next release(s). Thanks again.