lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734210#comment-13734210
] 

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...

{code}
  <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"/>
  </enum>
{code}

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...

{code}
  <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>
      <label>Highest</label>
    </value>
  </enum>
{code}

                
> new field type - EnumField
> --------------------------
>
>                 Key: SOLR-5084
>                 URL: https://issues.apache.org/jira/browse/SOLR-5084
>             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: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message