I overlooked a special constructor labelled “Expert” and discovered it
is possible… though I had to override numericValue which seems quite
hacky:
private static class ComboField extends Field {
private ComboField(String name, Object value, FieldType type) {
super(name, type);//this expert constructor allows us to have a
field that has docValues & indexed
super.fieldsData = value;
}
//Is this a hack? We assume that numericValue() is only called
for DocValues purposes.
@Override
public Number numericValue() {
if (fieldType().numericType() == FieldType.NumericType.DOUBLE)
return Double.doubleToLongBits(super.numericValue().doubleValue());
//TODO others
throw new IllegalStateException("unsupported type:
"+fieldType().numericType());
}
}
Why isn’t supporting a single Field with DocValues & indexed, etc.
supported more officially?
Any way, I’ll go with this for now. FYI this very class is going to
show up in spatial BBoxStrategy in a new patch soon.
~ David
On Thu, Jul 3, 2014 at 12:48 PM, [email protected]
<[email protected]> wrote:
> I was experimenting with having a user-provided/customized FieldType
> for indexing code of (mostly) a set of numeric fields that are of a
> common type. The user/developer might want the type to both be
> indexed & have docValues, or perhaps just one. Or maybe stored
> hypothetically for the purposes of this discussion. Even though
> Lucene’s FieldType allows you to configure both DocValues &
> indexed=true, it appears impossible to provide a single Field instance
> with both options; the constructors force an either-or situation. Of
> course I know I could add more fields depending on the options (for
> example as seen in Solr’s FieldType); but I think it’s awkward. It
> *seems* that Lucene’s indexing guts (DefaultIndexingChain) are
> agnostic of this. Wouldn’t it be great if you could simply provide a
> Field with a value and FieldType (with various options) and it’d just
> work? Higher up the stack (Solr and presumably ElasticSearch), there
> are abstractions that basically make this possible, but why not at the
> Lucene layer?
>
> ~ David
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
