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
Should we let the
user decide whether it's OK to use an asynchronous index for this case
+1 for that. It has been the case with JR2 (I may be wrong here). And
when user is searching for say some asset via DAM in Adobe CQ then he
would be ok if result is not for latest head. A small lag should be
-
From: Chetan Mehrotra [mailto:chetan.mehro...@gmail.com]
Sent: 14 April 2014 14:48
To: oak-dev@jackrabbit.apache.org
Subject: Re: Using Lucene indexes for property queries
Should we let the
user decide whether it's OK to use an asynchronous index for this case
+1 for that. It has been
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
