Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Thu, 24 May 2012 21:49:48 +0000 (UTC)
From: "Randall Hauch (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <947665845.109.1337896188374.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <828215324.9619.1337276407324.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (JCR-3313) JCR TCK Test for expanding column names
 is too restrictive
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/JCR-3313?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated JCR-3313:
-------------------------------

    Status: Patch Available  (was: Open)

Please apply this patch for inclusion in 2.4.1 and the next 2.x release. Th=
anks.
               =20
> JCR TCK Test for expanding column names is too restrictive
> ----------------------------------------------------------
>
>                 Key: JCR-3313
>                 URL: https://issues.apache.org/jira/browse/JCR-3313
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-tests, JCR 2.0
>    Affects Versions: 2.4.1
>            Reporter: Randall Hauch
>         Attachments: 0001-JCR-3313-Changed-a-ColumnTest-test-to-only-chec=
k-for.patch
>
>
> The 'org.apache.jackrabbit.test.api.query.qom.ColumnTest.testExpandColumn=
sForNodeType()' test method issues the following query:
>     SELECT s.* FROM [nt:unstructured] AS s
> and then proceeds to check that the columns in the results set. However, =
a problem with the expectations in the test: the test assumes that the resu=
lt set *only* contains columns for the single-valued, non-residual property=
 definitions for the selected node type. Clearly this is overly constrainin=
g, since Section 6.7.1 of the JSR-283 specification clearly allows an imple=
mentation to return additional columns (e.g., multi-valued property definit=
ions). Here's the relevant parts of this section:
>     A Query consists of:
>     ...
>     =E2=80=A2 A list of zero or more Columns to include in the tabular vi=
ew of the query results.=20
>       If no columns are specified, the columns available in the tabular v=
iew are implementation=20
>       determined, but minimally include, for each selector, a column for =
each single-valued=20
>       non-residual property of the selector's node type.
> In the test's query, no columns are specified for the selector 's', so th=
e result set must to have AT A MINIMUM  the columns for the single-valued n=
on-residual property defined on the selector's node type, but an implementa=
tion CAN include columns for other properties defined on the selector's nod=
e type. An implementation is even allowed to include columns that do not ma=
p to properties defined on the selector's node type (e.g., pseudo-columns t=
hat don't really exist as properties).
> The test's query uses "nt:unstructured" for the test node type (if not ov=
erridden by the test environment), and in this case an implementation shoul=
d be allowed to include the 'jcr:mixinTypes' multi-valued property.
> Therefore, the test is overly strict and should not fail when extra colum=
ns are included. The correct behavior is to test only that the result inclu=
des AT LEAST a column for each single-valued non-residual property on the s=
elector's node type.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira