[
https://issues.apache.org/jira/browse/OAK-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-1076:
---------------------------------
Attachment: OAK-1076.patch
This is now about wildcards in the property constraint.
If given a query like the following:
{code}
//*[(*/@prop > 1)]
{code}
the query engine will transform the PropertyValue it into a multi property
string and fallback to comparing strings instead of numerals.
I'm attaching a patch to address some of the issues around properly typing the
value used to compare against, but looking at the way the current code works,
it will not be possible to match on wildcards without transforming to string in
some cases (left a TODO in the code).
What I fixed is:
- in the case there is a single property match, return it with the initial
type, if there are more than one properties, they will be merged into a
multi-valued string property (old mechanism)
- fixed an issue with the wildcard match in the case of a constraint of type
_*/name_ where the query engine will return the good node (the parent) but also
the child node that had the property.
[~tmueller] feedback needed :)
> XPath failures for typed properties
> -----------------------------------
>
> Key: OAK-1076
> URL: https://issues.apache.org/jira/browse/OAK-1076
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, query
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Priority: Minor
> Fix For: 1.1
>
> Attachments: OAK-1076.patch
>
>
> It looks like there are some failures in xpath queries that expect a match
> only on properties of a certain type (which is to be inferred from the query)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
