lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Updated] (SOLR-11023) Need SortedNumerics/Points version of EnumField
Date Thu, 20 Jul 2017 23:04:01 GMT


Hoss Man updated SOLR-11023:
    Attachment: SOLR-11023.patch

step#0: refactor the init logic and xml parsing into an EnumMapping class.

I was initially thinking we could follow in the steps of CurrencyField and inject a new superclass
above EnumField (which would default to points) and the (legacy) EnumField could subclass
it and override as needed to use LegacyNumeric support where needed ... but the more i look
at it the more of a pain in the ass that appears to be.

the problem being I suspect we'll really want the "new" field type to extend PointField (or
maybe even IntPointField?) but we definitely don't want the legacy EnumField to transitively
extend PointField.

Alternative that's occuring to me now: make the new field type work a *lot* like CurrencyField,
where it wraps a concrete (int) fieldtype and delegates to for create/sort/etc -- only handling
the int/string converstion before/after.  then the legacy type just overrides what fieldtype
that hidden inner field uses?

frankly... EnumField has enough weird little quirks about it, that since we _know_ we want
to deprecate it and remove it in 8, I'm tempted to leave it alone as much as possible and
take the "i feel dirty" hit of cut/pasting all the bits we do really need to keep into a new
class that has nothing in common with it other then that they are both FieldTypes.

> Need SortedNumerics/Points version of EnumField
> -----------------------------------------------
>                 Key: SOLR-11023
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>              Labels: numeric-tries-to-points
>         Attachments: SOLR-11023.patch
> although it's not a subclass of TrieField, EnumField does use "LegacyIntField" to index
the int value associated with each of the enum values, in addition to using SortedSetDocValuesField
when {{docValues="true" multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality usecases
like EnumField, but either way we should think about a new variant of EnumField that doesn't
depend on LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses SortedNumericDocValues.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message