lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-5084) new field type - EnumField
Date Thu, 08 Aug 2013 23:55:48 GMT


Hoss Man commented on SOLR-5084:

bq. ...nested element underneath the field type? I dont know if this is even possible or a
good idea, but its an that would remove some xml files.

i don't think the schema parsing code can handle that -- it's attribute based, not nested
element based

bq. should we enforce from the enum config that the integer values are 0-N or something simple?

yeah ... it would be tempting to not even let the config specify numeric values -- just an
ordered list, except:

1) all hell would break loose if someone accidently inserted a new element anywhere other
then the end of the list
2) you'd need/want a way to "disable" values form the middle of the list from working again.

#2 is a problem you'd need to worry about even if we keep the mappings explicit but enforce
0-N ... there needs to be something like...

  <enum name="severity">
    <pair name="Not Available" value="0"/>
    <pair name="Low" value="1"/>

    <!-- value w/o name passes validation but prevents it from being used --><
    <pair value="2"/> <!-- "Medium" use to exist, but was phased out -->

    <pair name="High" value="3"/>
    <pair name="Critical" value="4"/>       

    <!-- this however would fail, because we skipped 5-10 -->
    <pair name="Super Nova" value="11"/>

bq. ... This way, things like valuesources dont have to do hashing but simple array lookups.

I was actually thinking it would be nice to support multiple legal names (with one canonical
for respones) per value, but that would preent the simple array lookps...

  <enum name="severity">
    <value int="0"><label>Not Available</label></value>
    <value int="1"><label>Low</label></value>

    <!-- value w/o name passes validation but prevents it from being used --><
    <value int="2" /> <!-- "Medium" use to exist, but was phased out -->

    <value int="3"><label>High</label></value>

    <value int="4">
      <label canonical="true">Critical</label>

> new field type - EnumField
> --------------------------
>                 Key: SOLR-5084
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Elran Dvir
>         Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch
> We have encountered a use case in our system where we have a few fields (Severity. Risk
etc) with a closed set of values, where the sort order for these values is pre-determined
but not lexicographic (Critical is higher than High). Generically this is very close to how
enums work.
> To implement, I have prototyped a new type of field: EnumField where the inputs are a
closed predefined  set of strings in a special configuration file (similar to currency.xml).
> The code is based on 4.2.1.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message