lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorge Luis Betancourt Gonzalez <>
Subject Re: Solr(j) API for manipulating the schema(.xml)?
Date Sun, 21 Sep 2014 04:34:46 GMT
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 <> 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 [] 
> Gesendet: Mittwoch, 17. September 2014 19:56
> An:
> 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 <> wrote:
>> Is there an API to manipulate/consolidate the schema(.xml) of a Solr-core? Through
>> 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

View raw message