On Wed, Jun 10, 2009 at 12:13 PM, Alexander Klimetschek<[email protected]> wrote: > On Wed, Jun 10, 2009 at 9:45 AM, Bernd Fondermann<[email protected]> > 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
Hmmm, 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 > 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. > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected] >
