: But that's just it. There's no way for the EFF to point to any underlying type
: at all! Still, I can easily be persuaded that it'd be a bad thing to
I'm talking about configuration.
* this should be valid, because it has been valid in the past and we don't
want to break existing configs (and it doesn't hurt anything to let people
be explicit that they expect a 'float' style ValueSource)...
<fieldType name="float" class="solr.FloatField" omitNorms="true"/>
<fieldType name="file" keyField="id" defVal="1"
class="solr.ExternalFileField" valType="float"/>
* This should *not* be valid, because it has not been valid in the past
and implies it will do something special that it will not really do...
<fieldType name="long" class="solr.TrieLongField" omitNorms="true"/>
<fieldType name="file" keyField="id" defVal="1"
class="solr.ExternalFileField" valType="long"/>
* This should be valid (yes that means we need to change the init code)
and should be what we change all of the examples to be, since valType is a
No-Op anyway so let's stop advertising it...
<fieldType name="file" keyField="id" defVal="1"
class="solr.ExternalFileField" />
: make valType optional and document it as a no-op currently. We'll still error
if
: they make it anything except FloatField or TrieFloatField.
...or just stop documenting valType entirely. No reason to document it
until it actually does something useful.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
