lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: change in EnumField configuration - what do you think?
Date Mon, 02 Jun 2014 14:46:10 GMT
Would both then be supported? I see where it would be easily detectable.
And I also assume that this wouldn't break back-compat?


On Mon, Jun 2, 2014 at 6:22 AM, Elran Dvir <> wrote:

> Hi all,
> I am the one that contributed EnumField code to Solr.
> There was a long discussion how the integer values of an enum field should
> be indicated in the configuration.
> It was decided that the integer value wouldn't be written explicitly, but
> would be implicitly determined by the value order.
> For example:
> <enum name="severity">
>         <value>Not Available</value>
>         <value>Low</value>
>         <value>Medium</value>
>         <value>High</value>
>         <value>Critical</value>
> </enum>
> "Not Available" will get the value 0, "Low" will get 1 and so on.
> I have a use case where this configuration does not meet my needs.
> I have  an external system that indexes the data.
> One field has a closed set of values,  the values are sent as integer but
> should be represented as String. EnumField is perfect for it.
> The problem is that the values are predefined and not order sequentially
> (the values were "spaced" for future growth). It looks like this:
>     <enum name="myField">
>         <pair name="a" value="1000"/>
>         <pair name="b" value="1500"/>
>         <pair name="c" value="2000"/>
>         <pair name="d" value="2500"/>
>         <pair name="e" value="3000"/>
>     </enum>
> So I think we have to be able to indicate the integer values of an
> EnumField in the configuration.
> What do you think?
> Thanks.

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