Hi, In theory, the Lucene index could be used quite easily. As far as I see, we would only need to change the cost function of the Lucene index (return a reasonable cost even if there is no full-text constraint).
One problem might be: the Lucene index is asynchronous, and the user might expect the result to be up-to-date. The user knows this already for full-text constraints, but not for property constraints. Should we let the user decide whether it's OK to use an asynchronous index for this case? For example by specifying an option in the query (for example similar to the "order by", at the very end of the query, "option async")? So a query that can use an asynchronous index would look like this: //*[@prop = 'x'] option async or //*[@prop = 'x'] order by @otherProperty option async or select [jcr:path] from [nt:base] as a where [prop] > 1 option async Regards, Thomas On 14/04/14 06:54, "Chetan Mehrotra" <[email protected]> wrote: >Hi, > >In JR2 I believe Lucene was used for all types of queries and not only >for full text searches. In Oak we have our own PropertyIndexes for >handling queries involving constraints on properties. This I believe >provides a more accurate result as its built on top of mvcc support so >results obtained are consistent with session state/revision. > >However this involves creating a index for property to be queried. And >the way currently property indexes are stored they consume quite a bit >of state (at least in DocumentNodeStore). In comparison Lucene stores >the index content in quite compact form. > >In quite a few cases (like user choice based query builder) it might >not be known in advance which property the user would use. As we >already have all string property indexed in Lucene. Would it be >possible to use Lucene for performing such queries? Or allow the user >to choose which types of index he wants to use depending on the >usecase. > >Chetan Mehrotra
