Of course, and in that use-case you'd want a particular document to
appear in all three categories.
Another client may want the doc to appear in only the "most important"
category, however that's defined.
Another client may want the doc to appear in "the more recent" day
(assuming we're grouping by date). Or "the oldest day".
that's what I meant by " rather than do something which will be wrong
it throws an error". Whatever you choose will be "wrong" in some
use-case.
Your use-case is certainly valid, but nobody has come forward with a
patch to allow it that I know of.
Faceting works on multivalued fields, perhaps you can do something with that?
Best,
Erick
On Mon, Feb 26, 2018 at 9:10 AM, Vincenzo D'Amore <v.dam...@gmail.com> wrote:
> Hi Erick,
>
> please consider this case where there is a group products that are
> televisions.
>
> Now I have only one category per product, but in same cases like the
> television I could have more than one.
>
> Some products should be available simultaneously in more categories, thats
> why the field I was trying to group is a multivalue, for example:
>
> /home-video/televisions/tv-led (516)
> /home-video/televisions/tv-ultra-hd-4k (363)
> /home-video/televisions/smart-tv (19)
>
> So there can be a television that is simultaneously a TV led, a smart tv
> and is ultra hd 4k.
>
> So, for example, I should be able to submit the following query:
>
> - fq=available:true
> - fq=vertical:0
> - q=television
> - rows=3
> - group=true
> - group.field=category
> - group.limit=0
>
> So the returned groups should be something like this (this is the output I
> have now for the single value field)
>
> <lst name="grouped">
> <lst name="category">
> <int name="matches">51653</int>
> <arr name="groups">
> <lst>
> <str name="groupValue">/home-video/televisions/tv-led</str>
> <result name="doclist" numFound="516" start="0"
> maxScore="0.6224861">
> </result>
> </lst>
> <lst>
> <str name="groupValue">/home-video/televisions/tv-ultra-hd-4k</str>
> <result name="doclist" numFound="363" start="0"
> maxScore="0.5923965">
> </result>
> </lst>
> <lst>
> <str name="groupValue">/home-video/televisions/smart-tv</str>
> <result name="doclist" numFound="19" start="0" maxScore="0.5749302">
> </result>
> </lst>
> </arr>
> </lst>
> </lst>
>
>
>
> On Mon, Feb 26, 2018 at 4:44 PM, Erick Erickson <erickerick...@gmail.com>
> wrote:
>
>> What does "group by" mean on a field with more than one value? Say I
>> have "A" and "B" in the field in a single document. What group does it
>> go in, one labeld "A" or one labeled "B"?
>>
>> So IIUC, rather than do something which will be wrong it throws an
>> error if the field is defined as multiValued. And whatever option is
>> chosen (e.g. use the min or max or....) will be wrong sometime.
>>
>> Although admittedly the error is a bit obscure...
>>
>> Best,
>> Erick
>>
>> On Mon, Feb 26, 2018 at 7:37 AM, Vincenzo D'Amore <v.dam...@gmail.com>
>> wrote:
>> > Hi Amrit,
>> >
>> > thanks for your help.
>> >
>> > I know that only 5/10% of documents in the collection have more than one
>> > value for the field I was trying to group by.
>> >
>> > So there isn't a particular memory usage in this case. Do you know if
>> there
>> > is any other counter-indication I have to be aware of?
>> >
>> > I was thinking to avoid this problem hacking the source code and deploy a
>> > personalised version of Solr.
>> >
>> > Best regards,
>> > Vincenzo
>> >
>> >
>> >
>> > On Mon, Feb 26, 2018 at 3:22 PM, Amrit Sarkar <sarkaramr...@gmail.com>
>> > wrote:
>> >
>> >> Vincenzo,
>> >>
>> >> As I read the source code; SchemaField.java
>> >>
>> >> /**
>> >> * Sanity checks that the properties of this field type are plausible
>> >> * for a field that may be used to get a FieldCacheSource, throwing
>> >> * an appropriate exception (including the field name) if it is not.
>> >> * FieldType subclasses can choose to call this method in their
>> >> * getValueSource implementation
>> >> * @see FieldType#getValueSource
>> >> */
>> >> public void checkFieldCacheSource() throws SolrException {
>> >> if ( multiValued() ) {
>> >> throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
>> >> "can not use FieldCache on multivalued
>> field: "
>> >> + getName());
>> >> }
>> >> if (! hasDocValues() ) {
>> >> if ( ! ( indexed() && null != this.type.getUninversionType(this) )
>> ) {
>> >> throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
>> >> "can not use FieldCache on a field w/o
>> >> docValues unless it is indexed and supports Uninversion: "
>> >> + getName());
>> >> }
>> >> }
>> >> }
>> >>
>> >> Seems like FieldCache are not allowed to un-invert values for
>> >> multi-valued fields.
>> >>
>> >> I can suspect the reason, multiple values will eat up more memory? Not
>> >> sure, someone else can weigh in.
>> >>
>> >>
>> >>
>> >> Amrit Sarkar
>> >> Search Engineer
>> >> Lucidworks, Inc.
>> >> 415-589-9269
>> >> www.lucidworks.com
>> >> Twitter http://twitter.com/lucidworks
>> >> LinkedIn: https://www.linkedin.com/in/sarkaramrit2
>> >> Medium: https://medium.com/@sarkaramrit2
>> >>
>> >> On Mon, Feb 26, 2018 at 7:37 PM, Vincenzo D'Amore <v.dam...@gmail.com>
>> >> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > while trying to run a group query on a multivalue field I received
>> this
>> >> > error:
>> >> >
>> >> > can not use FieldCache on multivalued field:
>> >> >
>> >> > <?xml version="1.0" encoding="UTF-8"?>
>> >> > <response>
>> >> >
>> >> > <lst name="responseHeader">
>> >> > <bool name="zkConnected">true</bool>
>> >> > <int name="status">400</int>
>> >> > <int name="QTime">4</int>
>> >> > </lst>
>> >> > <lst name="error">
>> >> > <lst name="metadata">
>> >> > <str name="error-class">org.apache.solr.common.SolrException</
>> str>
>> >> > <str name="root-error-class">org.apache.solr.common.
>> >> > SolrException</str>
>> >> > </lst>
>> >> > <str name="msg">can not use FieldCache on multivalued field:
>> >> > categoryLevels</str>
>> >> > <int name="code">400</int>
>> >> > </lst>
>> >> > </response>
>> >> >
>> >> > I don't understand why this is happening.
>> >> >
>> >> > Do you know any way to work around this problem?
>> >> >
>> >> > Thanks in advance,
>> >> > Vincenzo
>> >> >
>> >> > --
>> >> > Vincenzo D'Amore
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Vincenzo D'Amore
>>
>
>
>
> --
> Vincenzo D'Amore
