valType is NOT optional at all, at least in the 3x code line.
You get errors like this on startup if you leave it out:
Dec 14, 2011 2:07:48 PM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: Missing parameter
'valType' for FieldType=eff_float{keyField=id, defVal=1}
at org.apache.solr.schema.FieldType.getArg(FieldType.java:121)
and Solr goes downhill from there.
And now I see why I prompt with questions before diving in *too* far.
Your comments made me look at the rest of the class (I mean it's
another 25 lines down in the file, after all....) and there's this little
gem of a method:
@Override
public ValueSource getValueSource(SchemaField field, QParser parser) {
// default key field to unique key
SchemaField keyField = keyFieldName==null ?
schema.getUniqueKeyField() : schema.getField(keyFieldName);
return new FileFloatSource(field, keyField, defVal, parser);
}
So the valType is, as you say, completely irrelevant because a FileFloatSource
is returned no matter what.
So I think I now propose to remove that check altogether. The code should
still work whether the valType is specified or not and make note that it
ignored for now. This is really no change in behavior, just documenting what
happens currently.
I'm assuming that we should still work with schemas that define it rather
than break someone's schema if it is there by, for instance, using a 3.5
schema file with valType in an EFF field with new code and the proposed
change.
On Wed, Dec 14, 2011 at 1:59 PM, Chris Hostetter
<hossman_luc...@fucit.org> wrote:
>
> : 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
