[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13736975#comment-13736975
]
Elran Dvir commented on SOLR-5084:
----------------------------------
Thank you all very much for your very quick feedback.
@Hoss,
1) I eliminated all formatting changes and attached a new patch. I hope
it'll be more readable now.
2) I will try to create unit test as soon as possible and attach it.
3) I returned the value as EnumFieldValue in JavaBin format because I
would like to allow for a use case of sorting the values when returned to my
application by SolrJ.
4) Maybe it could, but I tried to keep the implementation simple and it
didn’t appear to give much more value. If someone feels strongly about it I can
revisit the implementation
@Robert,
In the configuration, I chose to specify the numeric values because I want
to also enable indexing and querying numeric values.
For example, the queries risk:[1 TO 3] and risk:[Low TO High] are both
valid.
Currently:
- If a bogus string value is sent, the value is indexed as -1.
- If a bogus integer value is sent, if the value is not a negative
number, the value is indexed as is. If it’s negative – the value is indexed as
-1.
- The display value is of course string. If we don’t find a matching
label to the numeric value in the configuration, the actual numeric value is
displayed.
Adding a new value at the end, would work.
Changing a display string for a value, will also work for retrieving data –
new data will have to be inserted using the new name (or by int value)
Removing a legal value from the list would retrieve the numeric value for
existing data
I have no use case for removing a previously legal value, so I can either
document the behavior, or implement a different behavior – depending on how
this discussion goes
@Erick,
I didn't intend to make this type single valued on purpose, it’s just that my
use case is single valued. I changed the field's configuration to multi value
and it seems to work fine
(facet, pivot, stats, return stored field). Why do you say the assumption is
the type is restricted to single value?
Thanks again.
> 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
