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]
