[jira] [Assigned] (OAK-1000) Queries on node name fail if the name starts with a number
[ https://issues.apache.org/jira/browse/OAK-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned OAK-1000: --- Assignee: Thomas Mueller > Queries on node name fail if the name starts with a number > -- > > Key: OAK-1000 > URL: https://issues.apache.org/jira/browse/OAK-1000 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, query >Reporter: Alex Parvulescu >Assignee: Thomas Mueller > > The _NodeNameImpl_ encodes the node name when used in a query via the > _ISO9075.encode_ method. [0] > The problem appears when a node name starts with a number: the encode will > turn _123456_ into __x0031_23456_ thus failing the node name match. > [0] > http://svn.us.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/NodeNameImpl.java?view=markup#l80 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-1000) Queries on node name fail if the name starts with a number
[
https://issues.apache.org/jira/browse/OAK-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13758823#comment-13758823
]
Thomas Mueller commented on OAK-1000:
-
Interesting. It looks like a property type conversion / comparison problem, I
will investigate. There is a related test in oak-core that tests for
{code}
select [jcr:path] from [nt:base] where name() = 'My_x0020_Documents'
{code}
and expects "My Documents" to match.
> Queries on node name fail if the name starts with a number
> --
>
> Key: OAK-1000
> URL: https://issues.apache.org/jira/browse/OAK-1000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, query
>Reporter: Alex Parvulescu
>
> The _NodeNameImpl_ encodes the node name when used in a query via the
> _ISO9075.encode_ method. [0]
> The problem appears when a node name starts with a number: the encode will
> turn _123456_ into __x0031_23456_ thus failing the node name match.
> [0]
> http://svn.us.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/NodeNameImpl.java?view=markup#l80
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-1001) SegmentMK: 32bit support for the file backend
Jukka Zitting created OAK-1001: -- Summary: SegmentMK: 32bit support for the file backend Key: OAK-1001 URL: https://issues.apache.org/jira/browse/OAK-1001 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: Jukka Zitting Assignee: Jukka Zitting Instead of just logging a warning (OAK-848), the file backend of the SemgnetMK should work also on 32bit JVMs. To do this, it should use normal file IO instead of memory-mapped files, as the latter will quickly exhaust the available address space of a 32bit JVM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-1000) Queries on node name fail if the name starts with a number
[ https://issues.apache.org/jira/browse/OAK-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13758048#comment-13758048 ] Alex Parvulescu commented on OAK-1000: -- added a failing test with http://svn.apache.org/r1520083 > Queries on node name fail if the name starts with a number > -- > > Key: OAK-1000 > URL: https://issues.apache.org/jira/browse/OAK-1000 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, query >Reporter: Alex Parvulescu > > The _NodeNameImpl_ encodes the node name when used in a query via the > _ISO9075.encode_ method. [0] > The problem appears when a node name starts with a number: the encode will > turn _123456_ into __x0031_23456_ thus failing the node name match. > [0] > http://svn.us.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/NodeNameImpl.java?view=markup#l80 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-997) cleanup codebase: remove unneeded internal abstraction
Stefan Guggisberg created OAK-997: - Summary: cleanup codebase: remove unneeded internal abstraction Key: OAK-997 URL: https://issues.apache.org/jira/browse/OAK-997 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg the internal tree abstraction hides an essential implementation detail (content-hash based identifiers) from the very implementation, leading to confusing and sometimes awkward code. furthermore there's a considerable amount of code duplication. this internal tree abstraction should be removed for the sake of a cleaner codebase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-1000) Queries on node name fail if the name starts with a number
Alex Parvulescu created OAK-1000: Summary: Queries on node name fail if the name starts with a number Key: OAK-1000 URL: https://issues.apache.org/jira/browse/OAK-1000 Project: Jackrabbit Oak Issue Type: Bug Components: core, query Reporter: Alex Parvulescu The _NodeNameImpl_ encodes the node name when used in a query via the _ISO9075.encode_ method. [0] The problem appears when a node name starts with a number: the encode will turn _123456_ into __x0031_23456_ thus failing the node name match. [0] http://svn.us.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/NodeNameImpl.java?view=markup#l80 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-999) Version creates frozenNode children with orignial NoteType instead of frozenNode
Christan Keller created OAK-999:
---
Summary: Version creates frozenNode children with orignial
NoteType instead of frozenNode
Key: OAK-999
URL: https://issues.apache.org/jira/browse/OAK-999
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Affects Versions: 0.8
Reporter: Christan Keller
For a Version the the children of a the Versions FrozenNode have the the
NodeType of their origin if they are not rferenceable. Expected is
nt:frozenNode.
The JCR Spec is not explicit on the node-type for this Nodes but it is not
Compatible with JR2
Dummy Test Case that just starts a Oak Repository
{code}
public class Issue extends RepositoryBaseTest {
@Test
public void testVersionChild() throws RepositoryException {
Session admin = getAdminSession();
Node parent =
admin.getRootNode().addNode(getClass().getSimpleName()+System.currentTimeMillis(),
JcrConstants.NT_UNSTRUCTURED);
Node child = parent.addNode("child");
parent.addMixin(JcrConstants.MIX_VERSIONABLE);
admin.save();
VersionManager vm = admin.getWorkspace().getVersionManager();
Version v = vm.checkin(parent.getPath());
Node frozenChild = v.getFrozenNode().getNode(child.getName());
Assert.assertEquals(JcrConstants.NT_FROZENNODE,
frozenChild.getPrimaryNodeType().getName());
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-754) Pluggable Security Setup
[ https://issues.apache.org/jira/browse/OAK-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-754: --- Assignee: angela > Pluggable Security Setup > > > Key: OAK-754 > URL: https://issues.apache.org/jira/browse/OAK-754 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: angela >Assignee: angela > > container issue for all security features that should be pluggable at > runtime: > - authentication > - authorization > - user mgt > - principal mgt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-998) Node#orderBefore() is not JCR conform
[
https://issues.apache.org/jira/browse/OAK-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christan Keller updated OAK-998:
Description:
In case you call node.orderBefore("nodeName", "nodeName"), oak throws
IllegalArgumentException with message "limit is negative"
While you may reason that is a wrong useage the spec is explicit about the
expected behavior.
{noformat}If this node supports child node ordering, this method inserts the
child node at srcChildRelPath into the child node list at the position
immediately the child node at destChildRelPath.
To place the node srcChildRelPath at the end of the list, a destChildRelPath of
null is used.
Note that (apart from the case where destChildRelPath is null) both of these
arguments must be relative paths of depth one, in other words they are the
names of the child nodes, possibly suffixed with an index.
If srcChildRelPath and destChildRelPath are the same, then no change is made.
This is session-write method, meaning that a change made by this method is
dispatched on save{noformat}
was:
In case you call node.orderBefore("nodeName", "nodeName"), oak throws
IllegalArgumentException with message "limit is negative"
While you may reason that is a wrong useage the spec is explicit about the
expected behavior.
{noformat}If this node supports child node ordering, this method inserts the
child node at srcChildRelPath into the child node list at the position
immediately the child node at destChildRelPath.
To place the node srcChildRelPath at the end of the list, a destChildRelPath of
null is used.
Note that (apart from the case where destChildRelPath is null) both of these
arguments must be relative paths of depth one, in other words they are the
names of the child nodes, possibly suffixed with an index.
If srcChildRelPath and destChildRelPath are the same, then no change is made.
This is session-write method, meaning that a change made by this method is
dispatched on save{noformat}
> Node#orderBefore() is not JCR conform
> -
>
> Key: OAK-998
> URL: https://issues.apache.org/jira/browse/OAK-998
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 0.8
>Reporter: Christan Keller
>
> In case you call node.orderBefore("nodeName", "nodeName"), oak throws
> IllegalArgumentException with message "limit is negative"
> While you may reason that is a wrong useage the spec is explicit about the
> expected behavior.
> {noformat}If this node supports child node ordering, this method inserts the
> child node at srcChildRelPath into the child node list at the position
> immediately the child node at destChildRelPath.
> To place the node srcChildRelPath at the end of the list, a destChildRelPath
> of null is used.
> Note that (apart from the case where destChildRelPath is null) both of these
> arguments must be relative paths of depth one, in other words they are the
> names of the child nodes, possibly suffixed with an index.
> If srcChildRelPath and destChildRelPath are the same, then no change is made.
> This is session-write method, meaning that a change made by this method is
> dispatched on save{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-998) Node#orderBefore() is not JCR conform
[
https://issues.apache.org/jira/browse/OAK-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christan Keller updated OAK-998:
Description:
In case you call node.orderBefore("nodeName", "nodeName"), oak throws
IllegalArgumentException with message "limit is negative"
While you may reason that is a wrong useage the spec is explicit about the
expected behavior.
{noformat}If this node supports child node ordering, this method inserts the
child node at srcChildRelPath into the child node list at the position
immediately the child node at destChildRelPath.
To place the node srcChildRelPath at the end of the list, a destChildRelPath of
null is used.
Note that (apart from the case where destChildRelPath is null) both of these
arguments must be relative paths of depth one, in other words they are the
names of the child nodes, possibly suffixed with an index.
If srcChildRelPath and destChildRelPath are the same, then no change is made.
This is session-write method, meaning that a change made by this method is
dispatched on save{noformat}
was:
In case you call node.orderBefore("nodeName", "nodeName"), oak throws
IllegalArgumentException with message "limit is negative"
While you may reason that is a wrong useage the spec is explicit about the
expected behavior.
{If this node supports child node ordering, this method inserts the child node
at srcChildRelPath into the child node list at the position immediately the
child node at destChildRelPath.
To place the node srcChildRelPath at the end of the list, a destChildRelPath of
null is used.
Note that (apart from the case where destChildRelPath is null) both of these
arguments must be relative paths of depth one, in other words they are the
names of the child nodes, possibly suffixed with an index.
If srcChildRelPath and destChildRelPath are the same, then no change is made.
This is session-write method, meaning that a change made by this method is
dispatched on save}
> Node#orderBefore() is not JCR conform
> -
>
> Key: OAK-998
> URL: https://issues.apache.org/jira/browse/OAK-998
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 0.8
>Reporter: Christan Keller
>
> In case you call node.orderBefore("nodeName", "nodeName"), oak throws
> IllegalArgumentException with message "limit is negative"
> While you may reason that is a wrong useage the spec is explicit about the
> expected behavior.
> {noformat}If this node supports child node ordering, this method inserts the
> child node at srcChildRelPath into the child node list at the position
> immediately the child node at destChildRelPath.
> To place the node srcChildRelPath at the end of the list, a destChildRelPath
> of null is used.
> Note that (apart from the case where destChildRelPath is null) both of these
> arguments must be relative paths of depth one, in other words they are the
> names of the child nodes, possibly suffixed with an index.
> If srcChildRelPath and destChildRelPath are the same, then no change is made.
> This is session-write method, meaning that a change made by this method is
> dispatched on save{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-998) Node#orderBefore() is not JCR conform
Christan Keller created OAK-998:
---
Summary: Node#orderBefore() is not JCR conform
Key: OAK-998
URL: https://issues.apache.org/jira/browse/OAK-998
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Affects Versions: 0.8
Reporter: Christan Keller
In case you call node.orderBefore("nodeName", "nodeName"), oak throws
IllegalArgumentException with message "limit is negative"
While you may reason that is a wrong useage the spec is explicit about the
expected behavior.
{If this node supports child node ordering, this method inserts the child node
at srcChildRelPath into the child node list at the position immediately the
child node at destChildRelPath.
To place the node srcChildRelPath at the end of the list, a destChildRelPath of
null is used.
Note that (apart from the case where destChildRelPath is null) both of these
arguments must be relative paths of depth one, in other words they are the
names of the child nodes, possibly suffixed with an index.
If srcChildRelPath and destChildRelPath are the same, then no change is made.
This is session-write method, meaning that a change made by this method is
dispatched on save}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-997) cleanup codebase: remove unneeded internal abstraction
[ https://issues.apache.org/jira/browse/OAK-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-997. --- Resolution: Fixed Fix Version/s: 0.9 done in rev. 1520046 > cleanup codebase: remove unneeded internal abstraction > -- > > Key: OAK-997 > URL: https://issues.apache.org/jira/browse/OAK-997 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Fix For: 0.9 > > > the internal tree abstraction hides an essential implementation detail > (content-hash based identifiers) from the very implementation, leading to > confusing and sometimes awkward code. furthermore there's a considerable > amount of code duplication. > this internal tree abstraction should be removed for the sake of a cleaner > codebase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-996) Incorrect types for version result nodes
[ https://issues.apache.org/jira/browse/OAK-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-996. -- Resolution: Fixed Fix Version/s: 0.9 Fixed in http://svn.apache.org/r1520006 > Incorrect types for version result nodes > > > Key: OAK-996 > URL: https://issues.apache.org/jira/browse/OAK-996 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 0.8 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 0.9 > > > JCR query results always return Node instances. This is not quite correct > when the returned nodes are of type nt:version or nt:versionHistory. The > types should be Version or VersionHistory accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-996) Incorrect types for version result nodes
[ https://issues.apache.org/jira/browse/OAK-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757700#comment-13757700 ] Marcel Reutegger commented on OAK-996: -- Added test in revision: 1519992 > Incorrect types for version result nodes > > > Key: OAK-996 > URL: https://issues.apache.org/jira/browse/OAK-996 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 0.8 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > JCR query results always return Node instances. This is not quite correct > when the returned nodes are of type nt:version or nt:versionHistory. The > types should be Version or VersionHistory accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-996) Incorrect types for version result nodes
Marcel Reutegger created OAK-996: Summary: Incorrect types for version result nodes Key: OAK-996 URL: https://issues.apache.org/jira/browse/OAK-996 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Affects Versions: 0.8 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor JCR query results always return Node instances. This is not quite correct when the returned nodes are of type nt:version or nt:versionHistory. The types should be Version or VersionHistory accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-995) XPath: allow using RowIterator Row.getPath() for all queries
Thomas Mueller created OAK-995:
--
Summary: XPath: allow using RowIterator Row.getPath() for all
queries
Key: OAK-995
URL: https://issues.apache.org/jira/browse/OAK-995
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr, query
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
For some slightly complex XPath queries, when using the RowIterator, the method
Row.getPath() currently throws an exception. Example:
{code}
//hello[@x=1]/*[@y=1]
{code}
The problem is that this XPath query is converted to a SQL-2 query with more
than one selector. When calling Row.getPath(), the method doesn't know which
selector should be used.
When using the NodeIterator (using getNodes), there is a workaround in the code
(a "TODO"), but it is rather ugly.
Instead of using this workaround, it would be better to check the select column
list, and if there is only one selector (which is the case for XPath queries),
use that one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-994) XPath to SQL-2 conversion error for "element(..)"
[
https://issues.apache.org/jira/browse/OAK-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-994:
---
Component/s: query
> XPath to SQL-2 conversion error for "element(..)"
> -
>
> Key: OAK-994
> URL: https://issues.apache.org/jira/browse/OAK-994
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
>
> The following XPath query is not converted correctly:
> {code}
> //element(hello, nt:base)
> {code}
> It should be converted to
> {code}
> select [jcr:path], [jcr:score], * from [nt:base] as a
> where name(a) = 'hello' /* xpath: //element(hello, nt:base) */
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-993) Improve backward compatibility for Item.save and Item.refresh
[
https://issues.apache.org/jira/browse/OAK-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-993:
--
Summary: Improve backward compatibility for Item.save and Item.refresh
(was: Improve backward compatibilityfor Item.save and Item.refresh)
> Improve backward compatibility for Item.save and Item.refresh
> -
>
> Key: OAK-993
> URL: https://issues.apache.org/jira/browse/OAK-993
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Michael Dürig
>
> As described in OAK-132 and OAK-141, both methods are implemented by
> delegating back to the respective {{Session}} methods and writing a warning
> to the log. This might introduce difficult to diagnose errors for those
> clients that rely on being able to only save/refresh parts of the transient
> space. A better solution might be to detect whether a save/refresh covers all
> transient changes and only then delegate back to the respective {{Session}}
> operation but throw an {{UnsupportedRepositoryException}} otherwise.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-994) XPath to SQL-2 conversion error for "element(..)"
[
https://issues.apache.org/jira/browse/OAK-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-994.
Resolution: Fixed
Revision 1519928
> XPath to SQL-2 conversion error for "element(..)"
> -
>
> Key: OAK-994
> URL: https://issues.apache.org/jira/browse/OAK-994
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
>
> The following XPath query is not converted correctly:
> {code}
> //element(hello, nt:base)
> {code}
> It should be converted to
> {code}
> select [jcr:path], [jcr:score], * from [nt:base] as a
> where name(a) = 'hello' /* xpath: //element(hello, nt:base) */
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-989) Query parser doesn't decode paths
[ https://issues.apache.org/jira/browse/OAK-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757534#comment-13757534 ] Thomas Mueller commented on OAK-989: Revision 1519928: Also use decode for //x and //element(x, *) Revision 1519930: Test case > Query parser doesn't decode paths > - > > Key: OAK-989 > URL: https://issues.apache.org/jira/browse/OAK-989 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, query >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Fix For: 0.9 > > > The SQL2 parser doesn't correctly decode the path constraints, which can > result in queries with no result. > The fix is to apply a _ISO9075#decode_ similar to the way Jackrabbit did it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-994) XPath to SQL-2 conversion error for "element(..)"
Thomas Mueller created OAK-994:
--
Summary: XPath to SQL-2 conversion error for "element(..)"
Key: OAK-994
URL: https://issues.apache.org/jira/browse/OAK-994
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
The following XPath query is not converted correctly:
{code}
//element(hello, nt:base)
{code}
It should be converted to
{code}
select [jcr:path], [jcr:score], * from [nt:base] as a
where name(a) = 'hello' /* xpath: //element(hello, nt:base) */
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
