lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Rodenburg" <jeff.rodenb...@gmail.com>
Subject Re: Solr, operating systems and globalization
Date Thu, 18 Oct 2007 13:56:14 GMT
OK, this simplifies things greatly.  For C#, the proper culture setting for
interaction with Solr should be Invariant.

Basically, the primary requirement for Solrsharp is to be
"culturally-consistent" with the targeted Solr server to ensure proper
data-type formatting.  Since Solr is culturally-agnostic, Solrsharp should
be so as well.

Thanks for the clarification.

On 10/17/07, Chris Hostetter <hossman_lucene@fucit.org> wrote:
>
>
> : This is exactly the scenario.  Ideally what I'd like to achieve is for
> : Solrsharp to discover the culture settings from the targeted Solr
> instance
> : and set the client in appropriate position.
>
> well ... my point is there shouldn't be any cultural settings on the
> "targeted" Solr server that the client needs to know about.
>
> the communication between the server and any clients should always be in a
> fixed format independent of culture.  Any (hypothetical) culture specific
> settings the server has to have might affect teh functionality, but
> shouldn't affect the communication (ie: for the purposes of date
> rounding/faceting the Solr server might be configured to know what
> timezone to use for rounding to the nearest day is, or what Locale to use
> to compute the first first day of the week, but when returning that info
> to clients it should still be stringified in an abolute format (UTC)



: multi-lingual systems across different JVM and OS platforms.  If it *were*
> : the case that different underlying system stacks affected solr in such a
> : way, Solrsharp should follow the server's lead.
>
> if that were the case, the server would be buggy and should be fixed :)
>
> i don't know much about C#, but i can't really think of a lot of cases
> where client APIs really need to be very "multi-cultural" aware ...
> typically culture/locale type settings related to parsing and formatting
> of datatypes (ie: how to stringify a number, how to convert a date to/from
> a string, etc...).  when client code is taking input and sending it to
> solr it's dealing with native objects nad stringifying them into the
> "canonical" format Solr wants -- independent of culture.  when client code
> is reading data back from Solr and returning it it needs to parse those
> strings from the canonical form and return them as native objects.
>
> The only "culture" that SolrSharp should need to worry about is the
> InvariantCulture you described ... right?
>
>
>
> -Hoss
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message