lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Lorenz <lor...@shoptimax.de>
Subject AW: Re: Tagging and excluding Filters with BlockJoin Queries and BlockJoin Faceting
Date Wed, 24 Aug 2016 08:52:59 GMT
I tried that too, with no effect.

The excluded facet just disappears completely (even the value that is filtered on in the fq)
when using the exclusion that has been tagged, like it did before.
When using a random exclusion (e.g. foo) that facet is visible again in the result set, but
that's obviously not helpful, I just tried to see what it would do.

So this is my current research result:

When excluding a facet which has been tagged in a filter query, this facet corresponding to
the fq's tag disappears in the result set in solr 6.1 when using BlockJoin Queries and json
facets (which it shouldn't).

Let me know if you want me to do more research or have one more idea.


-----Ursprüngliche Nachricht-----
Von: Mikhail Khludnev [mailto:mkhl@apache.org] 
Gesendet: Mittwoch, 24. August 2016 09:06
An: solr-user <solr-user@lucene.apache.org>
Betreff: Re: Re: Tagging and excluding Filters with BlockJoin Queries and BlockJoin Faceting

Sure. There are might mismatch with expectation. However, the first guess is to put {!tag
into beginning. eg, check with fq={!tag=myTag}{!parent which='isparent:true'}color:blue

On Tue, Aug 23, 2016 at 4:05 PM, Tobias Lorenz <lorenz@shoptimax.de> wrote:

> Hi Mikhail,
>
> Thanks for replying so quickly with a suggestion.
>
> I'm a colleague of Stefan and working with him on our project.
>
> We tried composing our solr query with exclusion instructions, and the 
> result was that the facet excluded by tag did not show up anymore in 
> the result, instead of showing all values.
>
> Your example from the last comment, completed by our exlusion instruction:
>
> json.facet={
>   filter_by_children: {
>     type: query,
>     q: "isparent:false",
>     domain: {
>       blockChildren: "isparent:true"
>     },
>     facet: {
>       colors: {
>         type: terms,
>         field: color,
>         domain:{
>           excludeTags:myTag
>         },
>         facet: {
>           productsCount: "unique(_root_)"
>         }
>       }
>     }
>   }
> }
>
>
> and the corresponding filter query:
>
> fq={!parent which='isparent:true'}{!tag=myTag}color:blue
>
>
> Either this feature is not working yet, or we are making a mistake 
> using it.
> Of course we know it's still in development right now.
>
> Might you please have a look if we are doing something obviously wrong?
>
> Thanks,
> Tobias
>
>
>
> >The last comment at https://issues.apache.org/jira/browse/SOLR-8998 
> >shows the current verbose json.facet syntax which provides aggregated 
> >facet counts already. It's a little bit slower that child.facet.field.
> >Nevertheless, you can take this sample and add exclusion instructions
> into.
> >It should work. Let me know how does it, please.
> >
> >On Wed, Aug 17, 2016 at 5:35 PM, Stefan Moises <moises@shoptimax.de>
> wrote:
> >
> >> Hi Mikhail,
> >>
> >> thanks for the info ... what is the advantage of using the JSON 
> >> FACET
> API
> >> compared to the standard BlockJoinQuery features?
> >>
> >> Is there already anybody working on the tagging/exclusion feature 
> >> or is there any timeframe for it? There wasn't any discussion yet 
> >> in SOLR-8998 about exclusions, was there?
> >>
> >> Thank you very much,
> >>
> >> best,
> >>
> >> Stefan
> >>
> >>
> >> Am 17.08.16 um 15:26 schrieb Mikhail Khludnev:
> >>
> >> Stefan,
> >>> child.facet.field never intend to support exclusions. My 
> >>> preference is
> to
> >>> implement it under json.facet that's discussed under 
> >>> https://issues.apache.org/jira/browse/SOLR-8998.
> >>>
> >>> On Wed, Aug 17, 2016 at 3:52 PM, Stefan Moises 
> >>> <moises@shoptimax.de>
> >>> wrote:
> >>>
> >>> Hey girls and guys,
> >>>>
> >>>> for a long time we have been using our own BlockJoin 
> >>>> Implementation, because for our Shop Systems a lot of 
> >>>> requirements that we had were
> not
> >>>> implemented in solr.
> >>>>
> >>>> As we now had a deeper look into how far the standard has come, 
> >>>> we saw that BlockJoin and faceting on children is now part of the 
> >>>> standard, which is pretty cool.
> >>>> When I tried to refactor our external code to use that now, I 
> >>>> stumbled upon one non-working feature with BlockJoins that still 
> >>>> keeps us from using
> >>>> it:
> >>>>
> >>>> It seems that tagging and excluding Filters with BlockJoin 
> >>>> Faceting simply does not work yet.
> >>>>
> >>>> Simple query:
> >>>>
> >>>> &qt=products
> >>>> &q={!parent which='isparent:true'}shirt AND isparent:false 
> >>>> &facet=true &fq={!parent 
> >>>> which='isparent:true'}{!tag=myTag}color:grey
> >>>> &child.facet.field={!ex=myTag}color
> >>>>
> >>>>
> >>>> Gives us:
> >>>> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException:
> >>>> undefined field: "{!ex=myTag}color"
> >>>>          at org.apache.solr.schema.IndexSchema.getField(IndexSchema.
> >>>> java:1231)
> >>>>
> >>>>
> >>>> Does somebody have an idea?
> >>>>
> >>>>
> >>>> Best,
> >>>> Stefan
> >>>>
> >>>> --
> >>>> --
> >>>> ************************************
> >>>> Stefan Moises
> >>>> Manager Research & Development
> >>>> shoptimax GmbH
> >>>> Ulmenstraße 52 H
> >>>> 90443 Nürnberg
> >>>> Tel.: 0911/25566-0
> >>>> Fax: 0911/25566-29
> >>>> moises@shoptimax.de
> >>>> http://www.shoptimax.de
> >>>>
> >>>> Geschäftsführung: Friedrich Schreieck
> >>>> Ust.-IdNr.: DE 814340642
> >>>> Amtsgericht Nürnberg HRB 21703
> >>>>    ************************************
> >>>>
> >>>>
> >>>>
> >>>
> >> --
> >> --
> >> ************************************
> >> Stefan Moises
> >> Manager Research & Development
> >> shoptimax GmbH
> >> Ulmenstraße 52 H
> >> 90443 Nürnberg
> >> Tel.: 0911/25566-0
> >> Fax: 0911/25566-29
> >> moises@shoptimax.de
> >> http://www.shoptimax.de
> >>
> >> Geschäftsführung: Friedrich Schreieck
> >> Ust.-IdNr.: DE 814340642
> >> Amtsgericht Nürnberg HRB 21703
> >>   ************************************
> >>
> >>
> >
> >
> >--
> >Sincerely yours
> >Mikhail Khludnev
> >
> >
>



--
Sincerely yours
Mikhail Khludnev
Mime
View raw message