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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
