[jira] [Commented] (OAK-828) Full-text support for index aggregates
[ https://issues.apache.org/jira/browse/OAK-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13764190#comment-13764190 ] Thomas Mueller commented on OAK-828: Revision 1521786 includes a (currently disabled) test case LuceneIndexAggregationTest.testDifferentNodes to illustrate one of the problems. Full-text support for index aggregates -- Key: OAK-828 URL: https://issues.apache.org/jira/browse/OAK-828 Project: Jackrabbit Oak Issue Type: Bug Components: oak-lucene, query Reporter: Alex Parvulescu Assignee: Alex Parvulescu Attachments: aggregates.patch There's no support for indexing aggregates in Oak [0] I'd like to start slowly rolling some basic support in, so that at least assumptions like fulltext search on files work properly. [0] http://wiki.apache.org/jackrabbit/IndexingConfiguration -- 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-828) Full-text support for index aggregates
[ https://issues.apache.org/jira/browse/OAK-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759110#comment-13759110 ] Thomas Mueller commented on OAK-828: I think support for relative properties is independent and not directly related of aggregation. It looks like support for relative properties was broken in revision 1516744 as part of other changes. I will have a look. Full-text support for index aggregates -- Key: OAK-828 URL: https://issues.apache.org/jira/browse/OAK-828 Project: Jackrabbit Oak Issue Type: Bug Components: oak-lucene, query Reporter: Alex Parvulescu Assignee: Alex Parvulescu Attachments: aggregates.patch There's no support for indexing aggregates in Oak [0] I'd like to start slowly rolling some basic support in, so that at least assumptions like fulltext search on files work properly. [0] http://wiki.apache.org/jackrabbit/IndexingConfiguration -- 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-828) Full-text support for index aggregates
[ https://issues.apache.org/jira/browse/OAK-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13748392#comment-13748392 ] Alex Parvulescu commented on OAK-828: - I pushed in the patch with minor tweaks with rev 1516744. I had to review (and disable) some of the newer lucene tests (QueryFulltextTest#testFulltextRelativeProperty) as I think they fall somewhere in between normal queries and aggregates queries. It remains to be seen if it makes sense to support these types of queries without proper specs. What remains to be done is the rule refctoring bits, which can even be tracked in a dedicated issue. I'm going to leave this open for now, all of the tests pass but there might still be some minor issues. Full-text support for index aggregates -- Key: OAK-828 URL: https://issues.apache.org/jira/browse/OAK-828 Project: Jackrabbit Oak Issue Type: Bug Components: oak-lucene, query Reporter: Alex Parvulescu Assignee: Alex Parvulescu Attachments: aggregates.patch There's no support for indexing aggregates in Oak [0] I'd like to start slowly rolling some basic support in, so that at least assumptions like fulltext search on files work properly. [0] http://wiki.apache.org/jackrabbit/IndexingConfiguration -- 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-828) Full-text support for index aggregates
[
https://issues.apache.org/jira/browse/OAK-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747330#comment-13747330
]
Thomas Mueller commented on OAK-828:
... queries on the child node ... {{jcr:contains(jcr:content, 'dog')}}
Yes, the LuceneIndex currently supports that. It might be possible to extract
the logic to a separate class, so it doesn't have to be implemented multiple
times. But it might not be easy to do.
Full-text support for index aggregates
--
Key: OAK-828
URL: https://issues.apache.org/jira/browse/OAK-828
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-lucene, query
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Attachments: aggregates.patch
There's no support for indexing aggregates in Oak [0]
I'd like to start slowly rolling some basic support in, so that at least
assumptions like fulltext search on files work properly.
[0] http://wiki.apache.org/jackrabbit/IndexingConfiguration
--
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-828) Full-text support for index aggregates
[
https://issues.apache.org/jira/browse/OAK-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13744832#comment-13744832
]
Thomas Mueller commented on OAK-828:
Some minor remarks:
{code}
+// pass-through impl
+if (baseIndex.getNodeAggregator() == null) {
+return baseIndex.getCost(filter, rootState);
+}
+// TODO dummy implementation
return baseIndex.getCost(filter, rootState);
{code}
I guess we could you always use pass-though, no matter if there is an
aggregator or not; I don't think aggregation has a significant I/O cost (we
don't care too much about CPU cost really, unless it's a really heavy
operations such as PDF text extraction).
{code}
public Cursor query(Filter filter, NodeState rootState) {
+if (baseIndex == null) {
+return Cursors.newPathCursor(new ArrayListString());
+}
{code}
I would probably fail here if baseIndex is null, unless you need it for
testing. The problem is that it would hide a bug somewhere else (for example in
the configuration) if the index is used like that. If you need this for
testing, what about logging a warning index is used inappropriately, or using
a special switch so that it works for testing but fails otherwise.
{code}
if (filter instanceof FilterImpl)
{code}
I would avoid instanceof as changing the FilterImpl might break things. What
about creating a copy constructor FilterImpl(Filter copy), or a getCopy()
method in the Filter interface + FilterImpl class?
{code}
public String getPlan(Filter filter, NodeState rootState) { ... }
public String getIndexName() { ... }
{code}
I wouldn't do the pass-through branch. I think it's slightly better if it's
visible in the logs (and while debugging) that the AggregateIndex is in use.
{code}
+private IteratorString aggregates = null;
+
+private String item = null;
{code}
Initializing fields with null is not needed.
AggregationCursor: the fields aggregates and init are sometimes set to
false/true/null. I think this could be simplified. But I guess the most
important thing is that it works and is well tested :-)
... to be continued ...
Full-text support for index aggregates
--
Key: OAK-828
URL: https://issues.apache.org/jira/browse/OAK-828
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-lucene, query
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Attachments: aggregates.patch
There's no support for indexing aggregates in Oak [0]
I'd like to start slowly rolling some basic support in, so that at least
assumptions like fulltext search on files work properly.
[0] http://wiki.apache.org/jackrabbit/IndexingConfiguration
--
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-828) Full-text support for index aggregates
[
https://issues.apache.org/jira/browse/OAK-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13744923#comment-13744923
]
Thomas Mueller commented on OAK-828:
There is quite a number of tests, that's great!
{code}
return new ArrayListString().iterator();
{code}
I would use Iterators.empty(); instead :-)
The interface {{Rule}}: I guess it's there as a placeholder, to be used when
{{PropertyNameRule}} is added, right? What I would already try to do
differently is: currently {{Rule}}, is a marker interface, but could a
matches method be added, and the logic of {{SimpleNodeAggregator.getParents}}
be changed to call this method, instead of accessing the {{ChildNameRule}}
object directly? Usually I'm not against structs, but here maybe it's not
necessary.
There commented test JCR-3160, why is it commented? If not implemented yet,
wouldn't it be possible to use {{@Ignore}}?
Otherwise, that's it from my side.
Full-text support for index aggregates
--
Key: OAK-828
URL: https://issues.apache.org/jira/browse/OAK-828
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-lucene, query
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Attachments: aggregates.patch
There's no support for indexing aggregates in Oak [0]
I'd like to start slowly rolling some basic support in, so that at least
assumptions like fulltext search on files work properly.
[0] http://wiki.apache.org/jackrabbit/IndexingConfiguration
--
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-828) Full-text support for index aggregates
[ https://issues.apache.org/jira/browse/OAK-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736700#comment-13736700 ] Alex Parvulescu commented on OAK-828: - Renamed the issue. As Thomas pointed out, we'll try a different thing in oak, aggregating at query time. Full-text support for index aggregates -- Key: OAK-828 URL: https://issues.apache.org/jira/browse/OAK-828 Project: Jackrabbit Oak Issue Type: Bug Components: oak-lucene, query Reporter: Alex Parvulescu Assignee: Alex Parvulescu There's no support for indexing aggregates in Oak [0] I'd like to start slowly rolling some basic support in, so that at least assumptions like fulltext search on files work properly. [0] http://wiki.apache.org/jackrabbit/IndexingConfiguration -- 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
