Hello Marius,
I would
suggest to generate the schema and config, reloading every time there's a class
change.
That would mean re-indexing everything right? It would take to much time.
No for most cases.
A Lucene index is "just" a heap of "terms".
If you change the schema in that you add a new field, the impact on the index is zero.
If you rename a field, you need to reindex.
If you change the type of a field (or its analyzer) then you have to reindex.
If you delete a field, you leave some dirt, you'd have to reindex if you rewake this
field name.
I believe that
the query-expansion step, from title:x to title-en:x title-ft:x, etc… is best to be
controlled early so that applications can change that somehow. In curriki, this is done
with a custom query-component which uses the query-parser (with a default-field which does
not exist) then rewrites the query objects (which is a fairly easy game).
That's actually what I'm currently investigating. I'll try to extend
the ExtendedDismaxQParserPlugin, let it do its query parsing and then
expand the query with more query objects when the "field" name matches
some pattern (e.g. property_*)
I am not sure it's best practice, but as an application developer, I would enjoy if
this code was in a Groovy page.
paul