View Optimisation when using Fetch/LookUp

General
,
1

While doing view optimisation we noticed below behaviour:
Details of the daml template setup
Template T1 has

  • signatory A

  • observer B

  • key by A

  • maintainer A

  • choice C1 controller A do two things:

  • fetch some contract

  • exercise some other choice C2 on Template T2

Inside the Trees: I have 2 child views of FetchAction and ExerciseAction C2
Both view has

  • Confirmee: A
  • No Informee

I wonder why there’s no informee for both child views? shouldn’t B be the informee?
Even if I explicitly add B as observer to choice C1 , I still see no informee for both view
Can someone help to demistify this?

2

After some digging with @WallaceKelly and information provided by @Andreas_Lochbihler (Big thank you to both!)
we realised that the reason of above behaviour is due to
fetch, fetchByKey and lookUpByKey not inheriting observer from the parent choice (more details can be viewed here)

This will cause one or more not mergeable child views in a choice if we have at least one observer in the parent template and within the choice there’s one or more actions using fetch, fetchByKey and lookUpByKey.
To optimize for performance, as suggested by @Andreas_Lochbihler , what we can do is to wrap the fetches to a non-consuming choice and configure choice observers/controllers explicitly as we see fit.
However, the same cannot be done for lookUpByKey

1 Like