Personally, I’d stick with Solr’s “built-in” dynamic field definitions just keep things smooth for future developers and ease of matching up what you’ll see on this list and via other support channels.
You can use field aliasing if you know which dynamic field you want… fl=price:price_f sort of thing, so your client can deal with friendlier names. But, I don’t think there are any other reasons or best practices for dynamic field naming conventions. Personally I’d use _/underscore as a separator though (is ‘.’ even one of the legal characters we support? It’s not in a valid Java identifier, so I’d steer clear of it myself. — Erik Hatcher, Senior Solutions Architect http://www.lucidworks.com <http://www.lucidworks.com/> > On Jan 29, 2016, at 8:59 AM, Prateek Jain J <prateek.j.j...@ericsson.com> > wrote: > > > Hi, > > We have decided to use dynamic fileds in solr for some of our use-case. What > we found in examples that these are declared as: > > <dynamicField name="*_i" type="int" indexed="true" stored="true"/> > <dynamicField name="*_is" type="int" indexed="true" stored="true" > multiValued="true"/> > <dynamicField name="*_s" type="string" indexed="true" stored="true" /> > > It is based upon suffix approach. What we are think to implement is: > > <dynamicField name="additional.int.*" type="int" indexed="true" > stored="true"/> > <dynamicField name="additional.ints.*" type="int" indexed="true" > stored="true" multiValued="true"/> > <dynamicField name="additional.string.*" type="string" indexed="true" > stored="true" /> > > According to, second approach would be more human readable and maintainable. > We know that is technically feasible but our question is, > > > è Are there any best practices regarding naming convention of dynamic fields? > If yes, are there any valid reasons? > > è Can there be any pit-falls in future, if we go via suffix way? > > > Regards, > Prateek Jain
