I'd recommend "managed schema" rather than schemaless. They're related but distinct.
The problem is that schemaless makes assumptions based on the first field it finds. So if it finds a field with a "1" in it, it guesses "int". That'll break if the next doc has a 1.0 since it doesn't parse to an int. Managed schema uses the same underlying mechanism to change the schema, it just let's you control exactly what gets changed. Best, Erick On Fri, Jul 7, 2017 at 3:01 AM, Thaer Sammar <t.sam...@geophy.com> wrote: > Hi Jan, > > Thanks!, I am exploring the schemaless option based on Furkan suggestion. I > need the the flexibility because not all fields are known. We get the data > from RDF database (which changes continuously). To be more specific, we > have a database and all changes on it are sent to a kafka queue. and we > have a consumer which listen to the queue and update the Solr index. > > regards, > Thaer > > On 7 July 2017 at 10:53, Jan Høydahl <jan....@cominvent.com> wrote: > >> If you do not need the flexibility of dynamic fields, don’t use them. >> Sounds to me that you really want a field “price” to be float and a field >> “birthdate” to be of type date etc. >> If so, simply create your schema (either manually, through Schema API or >> using schemaless) up front and index each field as correct type without >> messing with field name prefixes. >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >> > 5. jul. 2017 kl. 15.23 skrev Thaer Sammar <t.sam...@geophy.com>: >> > >> > Hi, >> > We are trying to index documents of different types. Document have >> different fields. fields are known at indexing time. We run a query on a >> database and we index what comes using query variables as field names in >> solr. Our current solution: we use dynamic fields with prefix, for example >> feature_i_*, the issue with that >> > 1) we need to define the type of the dynamic field and to be able to >> cover the type of discovered fields we define the following >> > feature_i_* for integers, feature_t_* for string, feature_d_* for >> double, .... >> > 1.a) this means we need to check the type of the discovered field and >> then put in the corresponding dynamic field >> > 2) at search time, we need to know the right prefix >> > We are looking for help to find away to ignore the prefix and check of >> the type >> > >> > regards, >> > Thaer >> >>
