: if (ftype==null || !(ftype instanceof FloatField)) {
: throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
: "Only float (FloatField) is currently supported as external field
: type. got '" + ftypeS + "'");
...
: now that Trie fields support sortMissingFirst/Last, does it make sense
: to allow the "float" type too? I'm guessing here that
: sortMissingFirst/Last is why EFFs are restricted this way, but I
: haven't really dug into it.
I don't think i've ever looked closely at the internals of this field type
before, but I'm not sure that it really matters what field types are
allowed there -- it's not used for anything as far as i can tell. I can't
see any reason why the "valType" param exists at all (let alone the
insistence that it refer to a FloatField) the ExternalFileField completely
ignores the ftype once it has it.
(The fact that valType is totally optional suggests that the limitation
isn't really that big of a deal anyway)
I suspect the intent was that ExternalFileField *should* ultimatley be
able to return any "type" of ValueSource, and that the specified valType
would then dictate the ValueSource impl returned (so that if you used an
"IntField" you would get a ValueSource that "natively" dealt with int
values from the file, but if you used "DoubleField" it would natively
deal with double values.
changing that validation code to also accept TrieFloatField
doesn't seem like it would practically make any different w/o also
changing a lot about how the actaul value source is returned -- either
by adding more File_____Source classes or my generalizing FileFloatSource.
barring actual changes to those classes, a better way to deal with the "no
one uses FloatField anymore so this limitation is confusing" problem is to
just stop promoting/suggestion people use the valType at all (until the
day comes when it's actually useful for something) and focus on
documenting the fact that ExternalFileFields reads and returns
values of type "float" from the specified file.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
