Hi,

thank you very much! This generally works to get my count. I still need to put these columns in a datapoint list to generate charts and such. With the aggregate approach in my post I already get a list that I can assign to a datapoint list. With your approach I have several columns that need to be transformed.

Is your approach performance-wise a good idea? At the moment I don't have thousands of test-data, but over the years my application would have to deal with that.

Is one aggregate to calculate everything better than several aggregates to calculate each use case separately?

Looking forward to your experience!

Regards

This is what I'm ending up with:

The list I appended my counts to is the one I'm using for my chart:

Soo - what is better - several aggregates with few formula and an assign or one aggregate with several formula and several list appends?

Hi @Cassandra Zimmermann ,

Generally, doing something in a single aggregate + some post processing is probably faster than doing it in let's say 4 aggregates.

For this example, it is not entirely clear from your posts, but I think I understood from them that you have several properties (like Grunde, Verlust, Verlauf,...) and you would like to create a donut chart (or some other visualisation) for each with the count of how often it occurs ?

A separate aggregate for each of these charts is the most obvious approach.  It is easier to understand and maintain.  Make sure you have them as separate aggregates or data actions on your screen, so each can start rendering as soon as it's data is available.

But talking about maintainability, I'm not getting those ListAppends you do below your aggregate.  This makes your code more work to maintain, because when your business later on wants an extra 4th option in the system for Grund, you will have to also maintain this logic.  Why not just put in the chart every Grund that happens to be in the system (so just base the datapoint list on the total aggregate result list)

Dorine

Just to be complete (to be clear, I would not actually build it like this), but let's say there is a competition "try to do it in as little aggregates as possible", you could have a single aggregate, grouping on all the colums you want a chart for (Grunde, Verlauf,...) and then loop the resultset, adding the count to local counters per attribute value, and then use that as input for all your charts.

thank you very much for taking the time to help me!

yes, the use case you described is exactly what I want to achieve. At first I had the single-aggregate-approach on the screen but felt like it was too much. I ended up with a lot of aggregates:

 -to complete my statistic I probably need twice or thrice as much. That's why I wanted a "cleaner/clearer" solution.

concerning the list appends:

I've put the single aggregate in a server action and somehow need to get the data to my screen. My approach: adding the data to a variable list in the server action - e.g. the DatapointList_Gruende includes the counts for the different Gruende (Reasons in German), one of them would be "Eigenbedarf". The aggregate counts 4 "Eigenbedarf"s and with the list append I add them to the DatapointList... and so on.

After adding all the Gruende to its DatapointList it's assigned to the chart, giving me all my Gruende in one donut chart. 

With your approach I'd also need variables to get my values to the chart or would you suggest to have the aggregate on the screen? But I don't know how this would affect performance?

Looking forward to your insights!

no, what I'm suggesting is that you do a ListAppendAll with target list the output list of your action, source list the result of your aggregate, and the ListAppendAll will probably ask you then to do the 'mapping' (saying what attribute in the source feeds what attribute in the target) because they are not lists of the same type.

This avoids that you have to hardcode a separate ListAppend for each existing value of 'Gruende', and so when later the list of Gruende changes (i.e. your static entity records change), you will not have to maintain this piece of code.

yes, it's asking for a mapping but I can only choose 1 column as a value. Each column is a different kind of Gruende, and I need all Gruende for my chart. Unfortunately I can't map several datapoints - it's just asking for one mapping of a value/label etc.

each color needs to be in a different chart: 

In the chart for Gruende I need all of the yellow counts as a datapoint list

Thank you again and greetings!

I'm afraid you lost me.  If you share an oml or much more detail about your datamodel and what exact charts you are making, I could maybe understand what you are saying.

sorry if my explanations are confusing. I've attached the oml.

To see some statistic you need to add a person ("Übersicht" - "Person hinzufügen"), add a name etc. and scroll down to "Fallhistorie" - "+" - set a "Beginn" and "Ende" (preferably dates in 2024 so you can create the statistic for 2024) - activate "Räumungsklage" (checkbox) - set  a "Grund" and "Verlauf" - "Speichern".

Create several of these to fill the entities. Save with "Speichern"

• Statistic-w-server-Aggregates: approach with several aggregates in a server action. Here you have some additional column charts, these should also be created for the other "Fallhistorie"-Tabs/options. These aren't implemented on the other statistic sites yet
• Statistic-w-ListAppend: approach with one large aggregate and ListAppends
• Statistic-w-Client-Aggregates: several aggregates for each chart on the screen

Each Tab in "Fallhistorie" has its own charts (see the "not implemented" accordion items). Just to give you an idea how many charts (& aggregates) I'll need 

Thank you very much for trying to help me!!