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
Wrong count previews in owner facet #207
Comments
This can be reproduced with any queries returning high result counts, e.g. owner facet for: |
The basic problem here is that we are faceting over a field (the item owner) that's not in our data. This approach won't work for the entire catalog: if we query everything, we'd have to get all items, and create the owner facet from that. Instead, I suggest we add an
That way, we could simply facet over What do you think @dr0i @acka47? If it makes no sense to expose the owner in the data (but I do think it's useful for API usage), we could also create an internal Elasticsearch field or a custom aggregation. If we do want to expose it, we should add it on the Metafacture level. |
+1 from me. I already proposed embedding item information in the instance data, see #140. We might just reopen that issue. |
Using a child aggregation on our data querying "köln" seems to come with a plausible result:
I can imagine that the factor 3 in ration resources/items is a result of libraries holding more than one item. Is this acceptable or do you really want to have a ration of 1? Though I doubt that if we take the data from the child into the parent and subsequently have e.g. 3 same |
Reopening, see discussion starting in #278 (comment). |
This came up again, see #1169, where @hagbeck wrote:
I pointed out this problem in #278 (comment):
|
This came up again in context of the comparison of ALMA and ALEPH resources of UB Münster. Idealy this should be fixed before ALMA Fix replaces ALEPH-Morph. #1601 |
@blackwinter will take a look whether this should be added to milestone DigiBib or not. |
We would not be affected by this issue. |
Since owners are based on exemplar aggregations, and aggregation requests have a limited size, the owner counts are wrong (just the owners of the most frequent X exemplar, which are actually all 1). To fix this, we have to improve the efficiency of the aggregations processing to enable an aggregations request with unlimited size for exemplars.
The text was updated successfully, but these errors were encountered: