[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734178#comment-13734178
]
Robert Muir commented on SOLR-5084:
-----------------------------------
I agree with Hossman.. stick with it though, I really like the idea of an
efficient enumerated type.
A few other ideas/questions (just from a glance, i could be wrong):
* should we enforce from the enum config that the integer values are 0-N or
something simple? This way, things like valuesources dont have to do hashing
but simple array lookups.
* it isnt clear to me what happens if you send a bogus value. I think an
enumerated type would be best if its "strongly-typed" and just throws exception
if the value is bogus.
* should the config, instead of being a separate config file, just be a 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.
> 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
