CDMs - Computations are only updated "one layer deep"

Modeling
1

Hi all,

not 100% sure whether this is a modeling question or if this goes beyond that but I’m hoping that I just set up my CDMs or my computations wrong.

So in my application, I have nested CDMs, e.g. 1 “Parent” can be linked to several “Children” who in turn can be linked to multiple “Grandchildren”. I also have computations that run through these multiple layers. Now, I have the problem, that when something is updated in one entity, the computations are updated in all the entities directly linked to it but not in the entities that are indirectly linked.

As an example, I have built a simple workspace where one Parent can be linked to up to 99 Children and one Child can be linked to up to 99 Grandchildren. Grandchildren can plant Trees. For parents, all trees planted by their children are summed up. Let’s say there’s one parent “Adam” with one child “Brian” and two grandchildren “Christine” and “Charly”. Christine has planted 2 trees, Charly 3. That means Brian has 5 planted trees (2 from Christine, 3 from Charly) and Adam also has 5 planted trees (all 5 from Brian). Now, Christine has planted another tree, so I update her number of planted trees to 3. In my application, Brian’s number of planted trees is updated automatically immediately, but Adam’s number stays at 5. To get Adam’s number to update, I need to first open Brian’s document and save again. Because this is kind of hard to follow, I made a screen recording:
firefox_HvaA7w8HJD
You can observe the same behavior when I delete one of the grandchildren. Brian’s number is automatically updated but Adam’s isn’t:
firefox_wMDkFmQOgg
I always added all three models to the respective CDMs and kept the computations very basic. The computation for the number of trees for one of the children is:

Sum(/ChildGrandchild_RM*/Grandchild/Trees)

and for one of the parents:

Sum(/ParentChild_RM*/Child/Trees)

Any ideas on how I could have both computations update automatically when I update or delete one of the grandchildren?

Here’s my workspace:
<INTERNAL_LINK>

Best,

Lea

2

Hi @lea-clear-clover

Thanks for the question and for preparing a workspace :star_struck:. It greatly speeded up my ability to answer your question.

I’m not 100% sure of the cause of this but I can give you a fix that worked for me.

Current State
Your Parent_CDM currently references all the linked Children and Grandchildren documents. However, the Computation Rule, comp_Trees, only looks at the data from the Child Documents.

grafik
grafik1920×1152 162 KB

Sum(/ParentChild_RM*/Child/Trees)

This means that you have all the data available to you but don’t compute from the real source of truth (the number of Trees of each Grandchild), rather you force the computation to happen in multiple steps:

  1. Update the number of trees on a Grandchild Document (or delete the Grandchild)
  2. Let the system detect that the Grandchild Document has been updated
  3. Automatically recalculate the Child Document as the result of comp_Trees on Child_CDM might have changed
  4. Let the system detect that the Child Document has been updated
  5. Automatically recalculate the Parent Document as the result of comp_Trees on Parent_CDM might have changed

Solution
It seems like Step 4 isn’t happening. As I say, I’m not 100% sure why but the solution is easy - reference the Grandchild Documents that you have already included in Parent_CDM in the computation rule comp_Trees on Parent_CDM.

Sum(/ParentChild_RM*/ChildGrandchild_RM*/Grandchild/Trees)

In my opinion this is more correct as you have a single source of truth for the calculation. It also means that each generation could potentially plant trees themselves and you could calculate the Total Trees. Something like this…

Sum(/ParentChild_RM*/ChildGrandchild_RM*/Grandchild/Trees,
    /ParentChild_RM*/Child/Trees,
    /Parent/Trees)

The Total trees is always based on the true value from each layer, not on a helper field.

3

Thanks for the quick answer! That makes a lot of sense. Now I need to go back to my real workspace and check whether my computation chains actually point to the same source of truth as in this example or whether this is more complicated.

Besides that, I feel like your step 4 should actually happen and this seems like a bug to me. Can we ping somebody who knows whether this is intentional? Maybe someone from the Kernel team?

4

Sure, it’s more of a Data Services issue. @tomas-thin-gale do you know what’s happening here?

5

By default, Data Services (DS) does not perform computations on any results. To ensure computations are executed for specific models, please include all necessary models in the configuration property: mgmtp.a12.dataservices.documents.computation.enabledForModels. This property accepts a comma-separated list of document models, including CDMs.

For further details, refer to the documentation at:

6

My example uses the PreviewApp, so I assume that this configuration is not set. Do you know what the default intended behavior is in this case? Or if this is not a data services topic do you know which team would be appropriate?

7

Hey all,

in the PreviewApp, DataServices is configured to compute all documents for all models (the configuration is set to *).

Please be aware that those Computations on server-side are only done for the Search Index,the persisted documents are not changed.

So if you save the GrandChild document, Data Services (DS) does detect that

  • it needs to recompute all Child CDDs, but it does so only in the index. It does update all CDDs of Child_CDM in the search index, but it does NOT persist the changed values to the documents of Child_DM. → When you open the overview of Child_CDM, you will see the correct values (retrieved from the index) and if you open the form you will also see the correct values (because the CDD is computed again on the client side. When you look into the data that is transferred from DS to the client, you will find the old value for the number of trees in the child document. So after saving Christine with 3 trees, Brian’s CDD in the index will be updated to show 6 trees, this value will be shown in the CDM based overview. But the persisted document for Brian is not changed. An overview on the Child_DMs would still show Brian with 5 trees.)

  • it needs to recompute the Parent CDDs, but in there, the computation does only look into the Child documents. For Brian, it will find trees = 5. (The correct value 6 is only stored in the computed Child CDDs in the index, it is not persisted.) The Parent CDD update is thus based on this value.

So when you change Christine’s value:

  1. Brian’s number is updated to 6 in the index and shown in the CDM based overview
  2. trees = 5 would be shown in an overview (regular overview or in a Binding) on Child_DM
  3. when opening the form based on Child_CDM for Brian, Brian’s document will be loaded with trees=5, recomputed right away to show trees=6. when submitting this form, Brian’s document will be persisted with trees=6 this will trigger the recomputation of Adams number of trees
  4. the computation of Adams CDD in the index will now “see” the updated value for Brian and compute the value correctly.

So this works as designed.
You need to change the Computation as suggested by mcaemmerer.

(Unfortunately you have to duplicate the business logic, as A12 currently does not support to Include DMs with multiple rootgroups - so to include the Child_CDM into the Parent_CDM.
The new CDD Computation introduced with QueryAPI in 2025.06 will also not solve this issue.)

8

Hi @felix-blazing-river ,

thanks for the detailed explanation. It seems kind of sketchy to me that the computations will modify the search index only but not the persisted documents. That way, documents in the database are potentially outdated (because of changes in related documents) until they are manually “touched” by a user. But if this is the way A12 is designed, we will not reinvent the wheel for our project :smiley:

Designing the computations without subtotals is somewhat breaking my brain but it’s possible, so I’m marking @malcolm-silver-ice 's answer as the solution.

9

You can totally work with subtotals!

You just have to copy the Computation over.
So in Child_CDM there is Child.NumberOfTrees = Sum(ChildGrandchild_RM*/Grandchild/Tree)
And this Computation needs to be duplicated in Parent_CDM in the Child Level.
Then you can keep your Computation on ParentLevel as it is.

But you can also condense it into one big Computation as @malcolm-silver-ice suggested.