Hi Yonik, One approach I have been working on that I will integrate into SOLR is the ability to use serialized objects for the analyzers so that the schema can be defined on the client side if need be. The analyzer classes will be dynamically loaded. Or there is no need for a schema and plain Java objects can be defined and used.
I'd like to see the synonyms serialized as well. When I mentioned the serialization it is in regards to setting the configuration over the Hadoop RMI LUCENE-1336 protocol. Instead of creating methods for each new call one wants, the easiest approach in distributed computing is to have a dynamic class loaded that operates directly on SolrCore and so can do whatever is necessary to get the work completed. Creating new methods in distributed computing is always a bad idea IMO. In realtime indexing one will not be able to simply reindex all the time, and so either a dynamic schema, or no schema at all is best. Otherwise the documents would need to have a schemaVersion field, this gets messy I looked at this. Jason On Wed, Sep 17, 2008 at 5:10 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > On Wed, Sep 17, 2008 at 4:50 PM, Henrib <[EMAIL PROTECTED]> wrote: >> Yonik Seeley wrote: >>> >>> ...multi-core allows you to instantiate a completely >>> new core and swap it for the old one, but it's a bit of a heavyweight >>> approach.... >>> ...a schema object would not be mutable, but >>> that one could easily swap in a new schema object for an index at any >>> time... >>> >> >> Not sure I understand what we gain; if you change the schema, you'll most >> likely will >> have to reindex as well. > > That's management at a higher level in a way. > There are enough ways that one could change the schema in a compatible > way (say like just adding query-time synonyms, etc) that it does seem > like we should permit it. > >> Or are you saying we should have a shortcut for the >> whole operation of >> "creating a new core, reindex content, replacing an existing core" ? > > Eventually, it seems like we should be able to handle re-indexing when > necessary. > And we should consider the ability to change some config without > necessarily reloading *everything*. > > -Yonik >
