jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Hauch <rha...@gmail.com>
Subject Re: TCK / SQLPathTest.testChildAxisRoot
Date Thu, 28 Jun 2012 13:39:42 GMT
I would agree that a compliant implementation could return the root node for this test.  

On Thursday, June 28, 2012 at 8:27 AM, Thomas Mueller wrote:

> Hi,
>  
> Thanks a lot! I see the current Jackrabbit 2.x works as required by the specification.
I was worried there is a bug. Well, the specification is a bit strange because the SQL expression
('/' LIKE '/%') should clearly return true. But that's OK, there is no rule that a specification
can't be strange.
>  
> Unless I misread that part of the specification, a compliant specification *may* return
the root node for this test, right? In that case I will change the test case slightly, to
allow it (but not to require it).
>  
> Regards,
> Thomas
>  
>  
> From: Randall Hauch <rhauch@gmail.com (mailto:rhauch@gmail.com)>
> Reply-To: "dev@jackrabbit.apache.org (mailto:dev@jackrabbit.apache.org)" <dev@jackrabbit.apache.org
(mailto:dev@jackrabbit.apache.org)>
> To: "dev@jackrabbit.apache.org (mailto:dev@jackrabbit.apache.org)" <dev@jackrabbit.apache.org
(mailto:dev@jackrabbit.apache.org)>
> Subject: Re: TCK / SQLPathTest.testChildAxisRoot
>  
> Surprisingly, the test appears to be correct as written: the root node should NOT be
included in the results.
>  
> To see why, we have to look at Section 6.6.3.4 ("Path Constraint") in the JSR-170 specification,
since we're talking about JCR's original SQL language. In particular, the "Child node path
constraint" example shows the JCR SQL and XPath queries that find the children of the "/some/nodes"
node as:
>  
> SELECT * FROM my:type
> WHERE jcr:path LIKE '/some[%]/nodes[%]/%'
> AND NOT jcr:path LIKE '/some[%]/nodes[%]/%/%'
>  
>  
> and
>  
> /jcr:root/some/nodes/element(*, my:type)
>  
> These queries are the same pattern of query issued in the test, and basically show the
combination of LIKE and NOT LIKE that are required to find the children of a node.  
>  
> Other parts of the specification outline why this example works the way it does. Section
6.6.5.1 ("jcr:like function") defines the semantics of the wildcard characters as generally
used within LIKE predicates (and "jcr:like" in XPath):
>  
> "As in SQL, the character ‘%’ represents any string of zero or more  
> characters, and the character ‘_’ (underscore) represents any  
> single character."
>  
> while Section 8.5.2.2 ("Pseudo-property jcr:path") specifies the semantics "jcr:path"
pseudo column and narrows the semantics of using LIKE with "jcr:path" in the second-to-last
bullet point:
>  
> "Predicates in the WHERE clause that test jcr:path are only required to  
> support the operators =, <> and LIKE. In the case of LIKE predicates,  
> support is only required for tests using the % wildcard character as a  
> match for a whole path segment (the part between two / characters)  
> or within index brackets.…"
>  
> Because the '%' matches only a whole path segment, the "/%" literal only matches paths
that have at least one path segment, which means that it matches all descendants of the root
node.
>  
> I hope this helps.
>  
> Best regards,
>  
> Randall
>  
> > Hi,
> >  
> > The test case SQLPathTest.testChildAxisRoot runs the following SQL-1 query:
> >  
> >     SELECT * FROM nt:base WHERE jcr:path LIKE '/%' AND NOT jcr:path LIKE '/%/%'
> >  
> > It expected the result to be
> >  
> >     /jcr:system, /testroot, /testdata
> >  
> > Shouldn't "/" (the root node) also be part of the result? The '%' is supposed to
match zero or more characters.
> >  
> > Regards,
> > Thomas
> >  
>  


Mime
View raw message