Incorrect output for @sum aggregate about dokuwiki-strata HOT 2 CLOSED

You are correct that the results will seem a bit funny (especially when one is used to SQL queries): all results in strata act like sets in that only unique results are reckoned. In this case, what happens is that the table query projects ?who and ?beans, which leads to the following result set:

(?who=peter, ?beans=1)
(?who=peter, ?beans=2)

Note that both the tuesday and wednesday entries result in the same (peter, 2) result, and are therefore not both present in the result set. While somewhat unexpected, this is the correct behaviour for strata --- there is a way to get the results you want though.

The solution is to add a ?when variable to your query, and use the consider block to force strata to consider a variable as relevant:

<table ?who ?beans@sum >
?b is a: beans
?b who: ?who
?b when: ?when
?b beans: ?beans
group {
  ?who
}
consider {
  ?when
}
</table>

The consider block informs strata that a variable is relevant for the uniqueness of the results, even though it is not part of the displayed fields.

Let me know if this helps!

P.S.: In your example you have three entries with names. I'm assuming they are on different pages. If not, note that if you put multiple entries in a single page Strata will merge them unless you give them unique names. A quick example of this can be seen in issue #41.

from dokuwiki-strata.

Thank you, this explains the funny results perfectly well. I did not understand before the use for the consider block. Now I do.
The example is, of course, contrived and I put all the data on one page in order to simplify the documentation of the issue. The result of the query appears to be the same when I add names to the entries.
Instead of the field when, I can also use the entry title to disambiguate the rows.
All's well, the issue is solved, strata is an astonishingly flexible beast. Thank you.

from dokuwiki-strata.