jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ard Schrijvers <a.schrijv...@onehippo.com>
Subject Re: Controlling the Lucene indexing
Date Thu, 11 Jun 2009 11:04:31 GMT
On Wed, Jun 10, 2009 at 12:13 PM, Alexander Klimetschek<aklimets@day.com> wrote:
> On Wed, Jun 10, 2009 at 9:45 AM, Bernd Fondermann<bf_jak@brainlounge.de> wrote:
>>> i.e. create a regular JCR property instead of creating this
>>> low-level-behind-the-scences fields in lucene. then run the more
>>> sophisticated searches on those additional properties.
>>
>> How could that work? I could not differentiate using Lucene query field
>> qualifiers.
>
> For any additional metadata you want to search for, you compute it in
> your application (on write or in an observation listener) and put it
> into separate properties. These can then be used in your normal JCR
> Xpath or SQL search. This might not enable all advanced indexing
> features you can do with a plain Lucene, but should still cover a lot.
> And adding additional properties in JCR is fine - it's more about
> de-normalization than what you are typically taught with relational
> databases.

I think there are different camps in this, as also within my
direct Colleagues we have different favors: IMO, it feels natural to
index a property possibly in multiple ways, to index a date property
multiple times with different granularity etc etc. It is meant for
searching only, and I think anybody accustomed to something like Solr
does it all the time. The other camp seems to favor  always adding
just a property with some mangled values (date with granularity on
day).

As for efficient searching, you inevitable have some content
duplication, I'd favor this duplication in the lucene index only, and
not in the persisting layer.

Regards Ard

>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>

Mime
View raw message