lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elran Dvir (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5084) new field type - EnumField
Date Mon, 12 Aug 2013 15:54:50 GMT

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


Mime
View raw message