-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add exclusions to aggregation #26627
Comments
The grouping result is generated from the matches. Maybe it could be worth while to have a built-in Searcher that can do this. |
Exclusion is applied to the current color filter, but other filters must be applied. Which means we would build a second query with the same filters but the color filter to get the excluded color facet values. And we must do that for each excluded facet (color and size for instance). There can be tens of excluded facets, so performance is an issue, and all excluded queries must be called in parallel (same as #26579) I will do just that for my WooCommerce plugin. But it could be nice to build it in Vespa's yql syntax, as this is a very common e-commerce requirement. |
Why can't you do one query with no exclusions to get all these alternatives? |
Because exclusion is only among a facet items, not between facets. Here is the original query with 2 non-excluded facets color and size, returning one facet color and one facet size: Here is the query for excluded size, returning all sizes for the blue color: Here is the query for excluded color, returning all colors for the xxl size: |
In your example picture above is a gui which (I believe) shows all the options of each facets. That can be produced by one query, recalling all documents (or all documents matching the part of the query not set by facet selection). It also shows some facet values being selected, which leads to some choices of other facets being deactivated. The information needed for this is also one query, adding all selected facets as filters and deactivating all facet values not present in the resulting grouping. What am I missing? |
Exactly: it would require one query (no exclusion) + one query per excluded facet with a selection In my previous example:
And so on if more excluded facets are selected. |
Yes, it will be one query to respond to each new action taken by the user. That is normal and as expected right? And if we assume no state in the frontend, we'll need also need to redo the query without selection, so we get 2 queries per new user action. But we never need more than 2 queries at most per user action - agreed? |
No, because you must count excluded facets selected previously.
Total: for the whole sequence (1+ 2 + 3 + .. + 1 + N) = 1+ N*(N+1)/2 queries (instead of 1+N with non-excluded facets) The examples above with color and size required 3 queries, because both color and size where selected. |
Yes, N user actions give N+1 queries in total (not counting the first user action of opening the page/app). Agree? |
No, the last action gives N+1 queries. Total actions give O(N*N) queries
Total: 1 +2 + 3 + 4 = 10 queries |
Okay, back to the original question: Why does selecting 3 facets take 4 queries (assuming no state in the client)?
What additional information do you need at this point which is not returned by these two queries? |
More precisely, you get all choices for all non-excluded facets
We need to get the 3 aggregations, but each of them requires different where filters (same filters for each, without the current selection). Which gives 3 queries. Notice the filters below: the non-excluded filter remains, while each filter on the aggregation is removed: |
Why, i.e what information do you gain from this that is missing otherwise? |
Because the 3 aggregations cannot be calculated with the same where filters. Each one is calculated with the facet selection excluded (removed) from the where filters. Original query: Gives:
|
The first query (matching all) will give you all values of facet1, facet2 and facet3. |
The (matching all) query gives all values for facet1, facet2, facet3. But not all values for:
|
Yes, but those are subsets. You need the subset matching the current selection (of facet1,2,3), but what do you need the other subsets for? |
Let's go back to more precise examples. id: 1
id: 2
id: 3
id: 4
Let's combine aggregations from (1) (2) (3), to see expected excluded color(red) and size(11):
Results and non-excluded facet aggregations are coming from query (1). Query (2) and (3) are there only to calculate aggregations on excluded facets. |
Yes.
Can't you replace 2) and 3) by
This returns
You also have
From 1). Now you can combine them to create a view like in the image above:
That said, I think there is something in that image (but not in your example) that you won't get by 2 queries: |
The result should give But my original feature request is to have Vespa manage the whole thing server-side, from a YQL syntax addition. My examples are just here to explain what happens, and how one could do it client-side in the meantime. From my previous implementations, here are some hints:
|
Yes, 2 Red instead of 1 is an example of the same missing info (however, in that case I don't think it's necessarily better to show 1 than 2 if you show numbers at all since it may not be obvious to users what that number means.) Anyway, this is clear to me now, thanks for the patience! |
Closing inactive issue. |
On our backlog. |
E-Commerce facets often require to display "excluded" facet items from current selection.
For instance, let's say we selected the "Shoe" category. Each shoe has exactly one colour: blue or red.
If we select the blue filter, the red filter disappears, no way to also display red shoes:
X Blue
Color
But if we want to show the red excluded filter also, with a "OR" on the colour filter:
Show only blue shoes, but display the red excluded filter
X Blue
Red
Color
Show blue or red shoes
X Blue
X Red
Color
(See https://solr.apache.org/guide/solr/latest/query-guide/faceting.html#tagging-and-excluding-filters)
The text was updated successfully, but these errors were encountered: