Aggregation sum give 0 when empty

Hello dear community,

I would like to understand why when we use an aggregation SUM the return result has three logics:

  1. If the filter is blank, the aggregation sum all the records of the Tulip table (or more exactly the sum of the 1000 first records).
  2. If a filter is given in App Input, the aggregation do the job and sums the matched records.
  3. If the filter don’t exist in the table, the aggregation returns null.

It could be easier if the aggregation SUM would return the number 0 in case 1 and 3.

Thanks !

Hi @remi.bayon,

I’m sorry to disagree.

Case 1:
You put your Aggregation on a Query, limited to 1000. If the Query is not filtered, it includes all 1000 records, so does the aggregation. This is absolutely expected behaviour (how would you sum all values if it would deliver null?)

Case 2:
Aggregation on Query, Query Filterd → Sum on filterd list → expected bahaviour

Case 3:
Your screenshot shows an empty Variable, not a “0”. That is actually a null → expected behaviour.
If you transform the result into a text, it will display as “null”


Did I get you wrong anywhere? What is not feasible or what is missleading?

Hi Thorsten,

Thanks for answer, I understand it.
But to do honest, I find the case 1 counter-intuitive: ask nothing in the input field but get the sum of everything.
And same for case 3: my query get 0 record, so the sum of the weighing column of 0 record could be 0.

But ok, it is fine.

No it is not “ask nothing” it is “filter nothing” a filter usually removes (if you dont put a filter in a funnel everything runs through it. E.g. if you remove the paper filter on your coffee pour over, the ground coffee will fall right through to your drink.

If you dont put any filter on your EXCEL Table, you see all data…

1 Like

@thorsten.langner and @remi.bayon, I think there’s a middle ground here between how the product functions and what a reasonable expectation for the functionality is that makes this a fair product suggestion.

@remi.bayon, if I understand your ask correctly, your use-case assumes that data will be filtered by a user on the app end, and thus it would make sense for the aggregation not to display a value prior to that user input.

@thorsten.langner, you’ve correctly described how the feature currently behaves in Tulip, and what a user should expect given the current state of Table Queries and Aggregations.

As we think about the roadmap for this feature, it makes sense to consider whether applications that require an input should not return a value if the input value is blank/null/empty. In the last few weeks there have been a few questions regarding this exact same behavior—that features with filters display the full data set before a filter variable is applied—and its something we’re looking at internally.

1 Like