Hello XWiki devs,
I've been playing a bit to adapt the xwiki lucene plugin, actually the
curriki lucene plugin which is very similar, to the tastes of Intergeo.
One thing that surprised me is that most of the fields in the lucene
plugin are stored fields. This sounds like a big overkill when you
think that all the values of the fields of a document are loaded when
you have this document as match.
Not surprisingly, the curriki search result was almost only using
fullname, using lucene directly is somewhat faster, I think it's good
practice.
Could this be configurable? (i.e. the names of the fields that are
stored)
One powerful way to make it configurable would to migrate to solr
which bases on lucene but uses a schema that describes well type of
the fields.
Three other pluggeabilities I would wish:
- the search-result class really would wish to be subclassable, the
configuration could define a search-result-factory or something such
which would help (a lot) as a cursor exploiting the hits list
- I deem it very important to also have query expansion but maybe that
can be inside the rest of the application
- what is indexed how should also be subclasses (a pluggeable factory
for ObjectData?)
Finally, I wanted to use different analyzers per language, using the
Snowball family of analyzers so that stemming really does happen.
I kind of have it now but I would like to test it in unit tests and,
well... how can I do that?
Is there a way to get a "unit-test xwiki environment" (context, xwiki)
where my unit tests would create a few documents then query them?
Is there active work on this plugin?
Which patch is most interesting for the others?
paul
Attachments:
- smime.p7s
(application/pkcs7-signature — 2.2 KB)