: However, SolrSharp culture settings should be reflective and consistent with
: the solr server instance's culture. This leads to my question: does Solr
: control its culture & language settings through the various language
: components that can be incorporated, or does the underlying OS have a say in
: how that data is treated?
As a general rule:
1) Solr (the server) should operate as culturally and locally agnostic as
possible.
2) Solr Clients that want to act "culturally appropriate" should
explicitly translate from "local" formats to "absolute" concepts that
it sends to the server. (ala: the absolute unambiguous date format)
Ideally you should be able to take a Solr install from one box, move it to
another JVM on a different OS in a different timezone with different
Locale settings and everything will keep working the same.
(I think once upon a time i argued that Solr should assume the
charencoding of the local JVM, and wiser people then me pointed out that
was bad).
There may be exceptions to this -- but those exceptions should be in cases
where: a) the person configuring Solr is in completley control; and b) the
exception is prudent because doing the work in the client would require
more complexity. Analysis is a good example of this: we don't make the
clients analyze the text according to the native language customs -- we
let the person creating the schema.xml specify what the Analysis should
be.
As i recal, the issue that prompted this email had to do with C# and the
various cultural ways to specify a floating point number: 1,234 vs 1.234
(comma vs period). this is the kind of thing that should be translated in
clients to the "canonical" floating point representation. ... by which i
mean: the one the solr server uses :)
*IF* Solr has the behavior where setting the JVM local to something random
makes Solr assume floats should be in the comma format, then i would
consider that a Bug in Solr ... Solr should allways be consistent.
-Hoss
