[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
