lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-2348) No error reported when using a FieldCached backed ValueSource for a field Solr knows won't work
Date Tue, 08 Feb 2011 02:24:57 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message