Le 02-févr.-10 à 14:37, Sergiu Dumitriu a écrit :
I looked a bit at the code, and it is very focused on your needs.
Personally, I'd suggest that you go ahead and use it, since it will
be a
while until we can implement something more generic, and it definitely
won't work with a 1.5 core (probably not even with a 2.2 core).
Really ? Why?
The idea of launching this thread was really for this purpose: a
generic pluggeable index tuner. Currently the index is very broad and
multifunction but it needs to drop more for performance.
I am surprised you consider LuceneIndexProfile (not the I2G
implementations!) as being specific.
Sure, I've put the I2G-implementations inside it but that's a
different story, just a matter of code distribution.
In your approach, there's only one implementation
that handles the
decisions. In my approach, there can be several implementations,
each one handling its part. This means that you can write a custom
implementation for i2geo, but it won't be suited for a bigger
environment, where several different applications are installed and
each one would benefit from customizing the index. So, each
application could also come with its own indexing rules: the blog,
the calendar, the user management...
Cascading these filters ensures that there can be several cross-
cutting indexing rules that apply to the same entity,
Mmh, I see. That sounds useful indeed.
Note, oh note, that there's no real easy way to update a lucene-
document, e.g. adding a filter or removing a field. At least that I
know of.
I am not sure your proposal makes sense though since there's only one
search application.
One could maybe think of using multiple LuceneIndexProfile and allow
these to answer yes/no/i-don-t-know (e.g. a java.lang.Boolean) for
boolean-methods; use -1, 0, or positive for trims, use; null or an
object for sub-classes (and fall-back on the default).
I realized that I missed a method in the LuceneIndexProfile for the
analyzer also (which is quite fundamental).
Would that go in your direction?
paul