@Antoine , indeed, I understand now as you make a 2 step aggregation with ods-subaggregation widget. And therefore you suffer from this limit.Â
Â
The big problem here is not the limit from the API. It’s the fact that the API don’t provide a two step aggregation that would suits your need.Â
Because when you do this kind of trick, you must keep in mind that you’ll download the entire output from the API (20 000 rows) and then, parse them and compute another aggregation.Â
It the API limit would be 100K or even with no limit, the page would be frozen and the experience would be very slow or even too long to load for the user.Â
So this kind of usage should be avoided and we often need to find another way to proceed.Â
In your case it’s clearly a limitation of the API, and the only way to resolve this would be to have an intermediary dataset based on the first step of aggregation : 1 record would be the SUM(power) by hour for 1 year of data for exemple (as in one year you have 24*31*12 hours, that is less than 20 000).
Or you limit your dashboard to get the biggest hour for only 1 year, by filtering your context that perform the analysis.Â
I clearly understand that it’s not ideal, I shared this topic internally and we have these usages in mind regarding API evolutions.Â
Â
Â
@Guillaume Perrin-Fabre ods-adv-analysis has two limits depending on the type of query.
When you list items, as it relies on /records endpoint, you have the 100 hits limitation. Asking for more will return an error from the API (I encourage you to always have the console opened to see the 400 errors in the console or network tab and read the API error as it’s explicit)
When you perform a groupby, you go through the aggregation endpoint/feature and therefore you’ll have the 20K hits limitation.
In your case, if you want to list and go beyond the 100 limit, add a groupby with all the fields listed in the select clause, it will output the same thing, but without the limitation.Â
Â
Auto-translation 🪄
@Antoine, en effet, je comprends maintenant que tu fasses une agrégation en 2 étapes avec le widget ods-subaggregation. Et donc tu souffres de cette limite. Le gros problème ici n'est pas la limite de l'API. C'est le fait que l'API ne fournit pas d'agrégation en deux étapes qui répondrait à tes besoins. Car lorsque tu fais ce genre d'astuce, tu dois garder à l'esprit que tu vas télécharger l'intégralité de la sortie de l'API (20 000 lignes) puis les analyser et calculer une autre agrégation. Si la limite de l'API était de 100 Ko ou même sans limite, la page serait gelée et l'expérience serait très lente voire trop longue à charger pour l'utilisateur. Ce genre d'utilisation doit donc être évité et nous devons souvent trouver un autre moyen de procéder. Dans votre cas, il s’agit clairement d’une limitation de l’API, et la seule façon de résoudre ce problème serait d’avoir un jeu de données intermédiaire basé sur la première étape d’agrégation : 1 enregistrement serait la SOMME (puissance) par heure pour 1 an de données par exemple (comme dans une année vous avez 24*31*12 heures, cela
