[
https://issues.apache.org/jira/browse/SOLR-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991771#comment-12991771
]
Hoss Man commented on SOLR-2348:
--------------------------------
My hope had been that this would be really straightforward, and a simple
inspection of the SchemaField (or FieldType) could be done inside the
FieldCacheSource to cover all cases -- except that FieldCacheSource (and it's
subclasses) is only ever given a field name, and never gets a copy of the
FieldType, SchemaField of even the IndexSchema to inspect to ensure that using
the FieldCache is viable.
This means that we have to take the same basic approach as SOLR-2339 - every
FieldType impl that utilizes a FieldCacheSource in it's getValueSource method
needs to check if FieldCache is viable for that field (ie: indexed, not
multivalued)
We could rename the checkSortability method I just added in SOLR-2339 into a
"checkFieldCachibility" type method and use it for both purposes, but:
* it currently throws exceptions with specific messages like "can not sort on
unindexed field: "
* I seem to recall some folks talking about the idea of expanding FieldCache to
support more things like UninvertedField does, in which case being multivalued
won't prevent you from using the FieldCache on a field which would ultimately
mean the pre-conditions for using a FieldCacheSource would change. We could
imagine the user specifing a function that takes in vector args to use to
collapse the multiple values per doc on a per usage basis (ie: in this function
query case, use the max value of the multiple values for each doc; in this
function query, use the average value of the multiple values for each doc;
etc...)
with that in mind, i think for now the most straight forward thing to do is to
add a "checkFieldCacheSource(QParser)" method to SchemaField that would be
cut/paste of checkSortability (with the error message wording changed) and make
all of the (applicable) FieldType.getValueSource methods call it. In the
future, it could evolve differently then checkSortability -- either removing
the "!multivalued" assertion completley, or introspecting the Qparser context
in some way to determine that neccessary info has been provided to know how to
use the (hypothetical) multivalued FieldCache (hard t ospeculate at this point)
> No error reported when using a FieldCached backed ValueSource for a field
> Solr knows won't work
> -----------------------------------------------------------------------------------------------
>
> Key: SOLR-2348
> URL: https://issues.apache.org/jira/browse/SOLR-2348
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 3.1, 4.0
>
>
> For the same reasons outlined in SOLR-2339, Solr FieldTypes that return
> FieldCached backed ValueSources should explicitly check for situations where
> knows the FieldCache is meaningless.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
