[jira] [Commented] (OAK-2005) Use separate Lucene index for performing property related queries

["Chetan Mehrotra (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172133#comment-14172133 ] 

Chetan Mehrotra commented on OAK-2005:
--------------------------------------

bq. Proposed patch for enabling sorting

[~amitjain] I just committed sort support as part of OAK-2196. Can you have a look at that and see if something needs to be updated there. One part where the approach differs is the usage of TypedOrderedFields like NumericDocValuesField, DoubleDocValuesField etc. Current approach so far used LongField, DoubleField with storage off and with that sorting works. So not sure if seprate fields should be added for ordering requirements

> Use separate Lucene index for performing property related queries 
> ------------------------------------------------------------------
>
>                 Key: OAK-2005
>                 URL: https://issues.apache.org/jira/browse/OAK-2005
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: oak-lucene
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>             Fix For: 1.2
>
>         Attachments: OAK-2005-1.patch, OAK-2005-2.patch, OAK-2005-fixes.patch, OAK-2005-sort.patch
>
>
> Oak Lucene has some support for working with multiple Lucene directories. Currently Oak uses a single Lucene directory to store the full text index. It would be worthwhile to investigate if we can use a separate Lucene index to store specific properties only and use it to perform property related queries.
> * A separate Lucene directory would be used to store explicitly configured list of properties
> * The properties would be stored with there type
> ** JCR Long - long
> ** JCR Double - double
> ** JCR Date - long - The data value can be stored in long but with lesser precision say upto second or even minutes
> * The values would stored "as is" i.e. without tokenization
> Possible benefits of such an index would be (ofcourse need be validated!)
> * Compact storage - Less memory would be used to store the index
> * Native support for Order By
> * Improved performance for like query - Specifically 'foo%', '%foo'



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)