Do these numeric values have any significance to the application, or are
they merely to reserve holes that will be later filled in without reindexing
existing documents? I mean, there is no API to retrieve the numeric values
or query them, right? IOW, they are not like stored values or docvalues,
right?
-- Jack Krupansky
-----Original Message-----
From: Erick Erickson
Sent: Monday, June 2, 2014 10:46 AM
To: solr-user@lucene.apache.org
Subject: Re: change in EnumField configuration - what do you think?
Would both then be supported? I see where it would be easily detectable.
And I also assume that this wouldn't break back-compat?
Best
Erick
On Mon, Jun 2, 2014 at 6:22 AM, Elran Dvir <elr...@checkpoint.com> 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.
