Thank you for your quick responses.
The numeric values are determined by external system which I don't have any
control of. There is a gap between values to reserve holes that may be filled
in later in the future.
The values are sent as integers. In Solr, there is no need to retrieve the
numeric values or query them. However, The numeric values determine the sorting
order of values.
In order to support both forms and for backward compatibility, let's introduce
a new attribute called explicit, which by default is false. This attribute will
be used to know which form to expect.
For example:
With explicit="false" ("explicit" can be omitted because it's the default):
<enum name="severity">
<value>Not Available</value>
<value>Low</value>
<value>Medium</value>
<value>High</value>
<value>Critical</value>
</enum>
With explicit="true":
<enum name="severity" explicit="true">
<pair name="Not Available " value="0"/>
<pair name="Low " value="1"/>
<pair name="Medium " value="2"/>
<pair name="High" value="3"/>
<pair name="Critical" value="4"/>
</enum>
Do you agree?
Thanks.
-----Original Message-----
From: Jack Krupansky [mailto:j...@basetechnology.com]
Sent: Monday, June 02, 2014 6:17 PM
To: solr-user@lucene.apache.org
Subject: Re: change in EnumField configuration - what do you think?
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.
>
Email secured by Check Point
