Wait, wait, wait. I cannot _believe_ I wrote this: bq: As far as changing the schema, there's no good way to do that that....
Utter nonsense. There's the whole "managed schema" that was added in the not too distant past whose _purpose_ is to change the schema via a REST API both in stand-alone and in SolrCloud. Siiigggh. Senility creeps up unnoticed. Best er...@onthewaytoaresthome.org On Sat, Sep 20, 2014 at 9:34 PM, Jorge Luis Betancourt Gonzalez <jlbetanco...@uci.cu> wrote: > 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
