[dna-issues] [JBoss JIRA] Commented: (DNA-468) Add XPath query language support

[ https://jira.jboss.org/jira/browse/DNA-468?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-468: ----------------------------------- Added more implementation to the LuceneSearchEngine to properly process the changes it observes from its source. Some of the individual requests can be processed by merging them (into the CreateNodeRequest or UpdatePropertiesRequests), while other kinds of requests require crawling the content (either the properties of a node or a whole subgraph), while still other kinds of events cause the wholesale re-indexing of the entire content. (We may be able to improve the logic so that we don't have to re-index in all of the latter cases.) Changed how the SearchEngineIndexer works so that it can perform multiple indexing operations using a single source connection and index session. This made it possible to use this in the LuceneSearchEngine.index(ExecutionContext,Iterable<ChangeRequest>) method as described in the previous paragraph. Added some test cases to verify that the LuceneSearchEngine is observing and updating correctly. Tried a number of simple scenarios, and verified (with searches AND queries) that the indexes are getting updated correctly (given the kinds of changes in the tests). Discovered that the Lucene indexes always need to be optimized prior to committing, so adjusted to '1' the number of changes allowed before optimization is done (in LuceneSearchWorkspace.CHANGES_BEFORE_OPTIMIZATION). While doing the above, I discovered it was possible to check the right-hand-side values used in property value constraints against the numeric index rule's minimum and maximum values. Consider a constraint 'year < 1800' and an index rule for the 'year' property. If the rule has a minimum value of '1900', then the constraint will never satisfy any values (the values will never be smaller than the minimum value of 1900), so we can use a 'MatchNoneQuery' query object for the constraint. Similarly, if the constraint uses a '!=' operator, then we can return a 'MatchAllDocsQuery' query object if the right-hand-side value is outside the range of values. This optimization is more important for numeric values, since Lucene's NumericRangeQuery can be expensive. Incidentally, one of the tests I added does some very simplistic baseline measurements of the additional time it takes to update the indexes to reflect the changes, and the times seem to be vary wildly (the set of changes and content size are still fairly small). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira