Basically you could create a bunch of dynamic fields (according to your needs) so basically creating a dynamic field for each type of data (and several combinations) and then you can create a small wrapper around Solrj that will wrap the patterns defined on your schema.xml in a more understandable way. Like this you will be able to abstract the manipulation of the schema.xml file and only introduce it when is really needed i.e a new field type with new analyzers, etc.
On Sep 18, 2014, at 3:16 AM, Clemens Wyss DEV <clemens...@mysign.ch> wrote: > as our framework so far only knows a few field types "dynamic field"s may be > the way to go... And if there are new fieldtypes the new schema can be > distributed through ZooKeeper > > -----Ursprüngliche Nachricht----- > Von: Erick Erickson [mailto:erickerick...@gmail.com] > Gesendet: Mittwoch, 17. September 2014 19:56 > An: solr-user@lucene.apache.org > Betreff: Re: Solr(j) API for manipulating the schema(.xml)? > > Right, you can create new cores over the rest api. > > As far as changing the schema, there's no good way to do that that I know of > programmatically. In the SolrCloud world, you can upload the schema to > ZooKeeper and have it automatically distributed to all the nodes though. > > Best, > Erick > > On Wed, Sep 17, 2014 at 2:28 AM, Clemens Wyss DEV <clemens...@mysign.ch> > wrote: >> Is there an API to manipulate/consolidate the schema(.xml) of a Solr-core? >> Through SolrJ? >> >> Context: >> We already have a generic indexing/searching framework (based on lucene) >> where any component can act as a so called IndexDataPorvider. This provider >> delivers the field-types and also the entities to be (converted into >> documents and then) indexed. Each of these IndexProviders has ist own lucene >> index. >> So we kind of have the information for the Solr schema.xml. >> >> Hope the intention is clear. And yes the manipulation of the schema.xml is >> basically only needed when the field types change. Thats why I am looking >> for a way to consolidate the schema.xml (upon boot, initialization oft he >> IndexDataProviders ...). >> In 99,999% it won't change, But I'd like to keep the possibility of an >> IndexDataProvider to hand in "its schema". >> >> Also, again driven by the dynamic nature of our framework, can I easily >> create new cores over Sorj or the Solr-REST API ? Concurso "Mi selfie por los 5". Detalles en http://justiciaparaloscinco.wordpress.com
