[
https://issues.apache.org/jira/browse/SOLR-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-2522:
---------------------------
Attachment: SOLR-2522.patch
bq. The main thing thats missing from this patch is the syntax -- getting
"min(multivalued_field_name)" to work is non trivial, so for now i just hacked
in a "minf(fieldname)" and "maxf(fieldname)" function to get something i could
write tests against -- working on the ValueSourceParser changes to get the
syntax we all want to work is the next big thing on the agenda.
The more i look into this, the harder i realize it is.
The root complexity is that the ValueSourceParsers all delegate to
FunctionQParser.parseValueSource() (or parseValueSourceList()) when expecting
an argument that can be an arbitrary (nested) ValueSource -- this is how min &
max work now. FQP.parseValueSource() handles the logic of figuring out what
hte argument is (literal, nested function, $variable, field name, etc...) and
if it's a field name, calls {{f.getType().getValueSource(f, this)}} on the
associated SchemaField -- which for multivalued fields throws an exception that
gets propogated up.
My initial thinking was that i could refactor parseValueSource() to support
another flag for either specifying the MultiValueSelector, or indicating that
we want a "defered evaluation" of the underlying SchemaFields (ie: return some
mock FieldBasedValueSource that doesn't call FieldType.getValueSource until
used, so the min/max functions can explicitly call getSingleValueSource()
instead if they encounter a single argument) but then i realized that because
of how FunctionQParser deals with $variable derefrencing -- and the QParser
abstraction (variables might refer to other queries, which get automatically
unwrapped if they are FunctionQueries) then even that type of refacotring
solution wouldn't work in simple use cases like this...
{noformat}
...
& fl=id,min($my_f)
& my_f=some_multi_valued_field_name
{noformat}
So I'm going to punt on getting the {{min(some_multi_valued_field_name)}} (and
{{max(some_multi_valued_field_name)}}) syntax working, and leave that as a
usibillitiy improvement for the future.
What I think is nice, clean, very feasible (so feasible i already implemented
it), solution for now (that can still serve as a useful "advanced" syntax
moving forward even if we add the simple syntax later) is to support
{{field(some_multi_valued_field_name,'min')}} -- ie: add a new optional 2nd arg
to the field() function.
----
This new patch has that new syntax supported, along with cleanup of most of the
nocommits.
I think it's pretty much good to go as is, but i want to still add some more
tests (see remaining nocommits)
> Change max() and min() to work on multiValued fields
> -----------------------------------------------------
>
> Key: SOLR-2522
> URL: https://issues.apache.org/jira/browse/SOLR-2522
> Project: Solr
> Issue Type: Improvement
> Reporter: Bill Bell
> Assignee: Hoss Man
> Attachments: SOLR-2522.patch, SOLR-2522.patch
>
>
> Switch max() and min() functions to work on multiValued fields so we can
> do sort=min(fieldname) asc and the sort would work on multiValued fields...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
