Ard Schrijvers wrote:
So, WDOT about indexing properties in seperate lucene Fields, and about possibly indexing more information of one property.
Because the number of distinct property names in jackrabbit is unlimited (think of nt:unstructured nodes), this would lead to a great number of files created by lucene. for each field (this actually changed with version 2.1) lucene creates a separate file. That's basically the reason why I put them all into one field. See [1] and [2]. We should probably re-consider using a 1:1 mapping between jcr property names and lucene fields, since we also got rid of the norms with [3].
My experience with lucene, is that indexing tactically, eases querying a lot, and gains you lots of performance. So, if you do agree on these changes, which I can try to build in Jackrabbit, then I think these changes might validate a new QueryHandler class to be build aside the old one. WDOT?
I'm all for making the index better, however I'm a bit skeptical when it comes to virtual fields. This is not just an optimization but a new jackrabbit specific feature that we would introduce.
regards marcel [1] http://lucene.apache.org/java/docs/fileformats.html#Normalization%20Factors [2] http://issues.apache.org/jira/browse/JCR-106 [3] http://issues.apache.org/jira/browse/JCR-1042
