Hi Yonik,
thank you for your quick reply.
(((I just send my original e-mail a second time (I did not confirm the
subscription so I thought it might not have been send the first time, I’m
sorry.))))
We are using SOLR 6.1.0. Sorry, I should have mentioned.
The low number is because of the test data. It’s not how it would look like in
production. That’s also why I was never wondering about 0 values in the
beginning. But now that I have tweaked the data I can see that it’s not
returning the values as it should. And in production there are values > 0 as
expected but the sum() returns 0 nevertheless, that’s why we are aware that
something is wrong.
In production the data is re-indexed constantly. Though, we might have changed
the field type from int to float. I’m not sure whether we have really
re-indexed from scratch after that, in production, but I think in my local env
I did re-create the index. I will check this out.
I’ll also play around with the range query, thanks for the tip!
Cheers,
Chantal
> That should work... what version of Solr are you using? Did you
> change the type of the popularity field w/o completely reindexing?
>
> You can try to verify the number of documents in each bucket that have
> the popularity field by adding another sub-facet next to cat_pop:
> num_pop:{query:"popularity:[* TO *]"}
>
> > A quick check with this json.facet parameter:
> >
> > json.facet: {cat_pop:"sum(popularity)“}
> >
> > returns:
> >
> > "facets“: {
> > "count":2508,
> > "cat_pop":21.0},
>
> That looks like a pretty low sum for all those documents.... perhaps
> most of them are missing "popularity" (or have a 0 popularity).
> To test one of the buckets at the top-level this way, you could add
> fq=shop_cat:"Men > Clothing > Jumpers & Cardigans"
> and see if you get anything.
>
> -Yonik
