Hi, This is about Jackrabbit 2.x; I'm working on the Oak query + indexing implementation do I don't have much insight there. Would you be interested to use Oak?
However, I guess it would make sense to create Jira issues, and provide patches and test cases, if you are interested in improving Jackrabbit. > Problem 1: > This difference makes it more difficult further processing the WEBDAV XML > query result for example. What is the problem exactly? I don't think your patch would pass the existing tests, and I guess some applications depend on the current behaviour. So it would be better to understand what the exact problem is. > Problem 2 > Problem 3 A test case that shows the exact steps would be good (source code, with assertions). Regards, Thomas On 24.04.18, 08:42, "Ronald Appelfelder" <[email protected]> wrote: Hi folks! The query result of equivalent queries depends on the used query language. This is irritating and should not happen. See also my complaint from more than a year ago: https://www.mail-archive.com/[email protected]/msg20894.html Problem 1: ---------- The columns jcr:path and jcr:score are added to the xpath/sql query result without being asked. This does not happen with JCR-SQL2. This difference makes it more difficult further processing the WEBDAV XML query result for example. Possible fix: --- jackrabbit-2.17.2.orig/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/QueryImpl.java 2018-04-04 15:26:34.000000000 +0200 +++ jackrabbit-2.17.2/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/QueryImpl.java 2018-04-23 17:32:08.402865558 +0200 @@ -185,14 +185,6 @@ } } - // add jcr:path and jcr:score if not selected already - if (!columns.containsKey(NameConstants.JCR_PATH)) { - columns.put(NameConstants.JCR_PATH, columnForName(NameConstants.JCR_PATH)); - } - if (!columns.containsKey(NameConstants.JCR_SCORE)) { - columns.put(NameConstants.JCR_SCORE, columnForName(NameConstants.JCR_SCORE)); - } - return columns.values().toArray(new ColumnImpl[columns.size()]); } Problem 2: ---------- As a result of a xpath/sql query, the property types are returned according to the node type definition. For properties that were not defined there, the type STRING is generally returned. For example, if the value of a property contains a date, xpath/sql returns the type STRING, JCR-SQL2 correctly returns the type DATE. Problem 3: ---------- As a result of a xpath/sql query, multi-value properties are returned as empty. JCR-SQL2 returns the multi-value properties as strings separated by spaces instead. See lines 343 to 346 in file jackrabbit-2.17.2/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/RowIteratorImpl.java if (p.isMultiple()) { // mvp values cannot be returned return null; } else { The comment in line 344 is wrong: An equivalent JCR-SQL2 query proves the opposite. Possible fixes for problems 2 and 3 (with unknown side effects): --- jackrabbit-2.17.2.orig/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/RowIteratorImpl.java 2018-04-04 15:26:32.000000000 +0200 +++ jackrabbit-2.17.2/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/RowIteratorImpl.java 2018-04-23 20:55:21.777421007 +0200 @@ -341,14 +341,19 @@ } else if (n.hasProperty(col.getPropertyName())) { Property p = n.getProperty(col.getPropertyName()); if (p.isMultiple()) { - // mvp values cannot be returned - return null; - } else { - if (p.getDefinition().getRequiredType() == PropertyType.UNDEFINED) { - return valueFactory.createValue(p.getString()); - } else { - return p.getValue(); + String s = ""; + Value[] values = p.getValues(); + + for (int i = 0; i < values.length; i++) { + if (i > 0) { + s += ' '; + } + s += values[i].getString(); } + + return valueFactory.createValue(s); + } else { + return p.getValue(); } } else { Name prop = resolver.getQName(columnName); Motivation: Some things are impossible without this fixes: For example, if you need multi-value REFERENCEs (has many associations) _and_ you want to keep the document order you have lost. With xpath/sql you can keep the document order, with JCR-SQL2 you can get multi-value REFERENCEs, but not both in one query. Some queries are also difficult to translate into JCR-SQL2, e.g. SELECT a_multi_value_property FROM ... WHERE jcr:path LIKE 'a/%/b/%' Now you could object that you can avoid the problems by simply calling result.getNodes() and continuing with it. But if you access Jackrabbit remote with PHPCR (Jackalope) that is not a good idea, because it kills the performance (extra roundtrip(s) with potentially large result sets to parse and process on the PHP side). Good remote performance is reachable only by processing the pure query result. However, the query result must be correct, complete and independent of the query language used. Thank you for your attention. Ronald Appelfelder
