jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: [jr3] Restructure Lucene indexing & make use of Lucene 2.9 features
Date Thu, 18 Feb 2010 12:09:32 GMT
Hi,

On 18.02.2010 10:37, Ard Schrijvers wrote:
> On Thu, Feb 18, 2010 at 10:35 AM, Ard Schrijvers
> <a.schrijvers@onehippo.com> wrote:
>> On Wed, Feb 17, 2010 at 5:15 PM, Thomas Müller <thomas.mueller@day.com> wrote:
>>> Hi
>>>
>>>> each property indexed in its own Lucene field
>>>
>>> Could you explain in more details? What is a 1:1 mapping? Do you mean
>>> each property type should have it's own index, or each property name
>>> should have its own index? Would this not increase the number of
>>> Lucene index files a lot?
>>
>> No, I mean that the current implementation is based on a Lucene
>> version that could not handle infinit number of unique lucene fields
>> (jcr can have any property name). Therefor, Jackrabbit indexes every
>> different jcr fieldname in the same lucene field, but prefix the value
>> with the jackrabbit fieldname. This has quite some disadvantages,
>> memory loss (terms are cached in lucene and in jackrabbit without the
>> fieldname prefix), and I think we cannot easily make use of the Lucene
>> trie range stuff making range queries on dates, doubles and longs
>> efficient
> 
> Addon: So my improvement would be to suggest to index every unique jcr
> fieldname in a unique lucene field, and do not prefix values as
> currently is being done. This makes lots of the lucene classes and
> queries in jr easier or redundant

Being by no means an expert in this field.... but this sounds very much
doable in the shorter time frame of 2.x release, right ?

Regards
Felix

> 
> Ard
> 
>>
>> Regards Ard
>>
>>>
>>> Regards,
>>> Thomas
>>>
>>
> 


Mime
View raw message