Access to transaction events in DAML Script

Questions
1

Have you considered that adding something to allow the developers to access contract archive/creation events for those 4 commands in DAML script? That can simulate the behaviour of Ledger API streaming service and will make writing testing cases a lot simpler.

In DAML Script, do we have equivalent command for lookupbykey, fetchbykey?
2

Do you need access to the full transaction stream or just to an individual transaction that results as part of a submit? For the latter, I have a branch that provides a submitTree function that returns the full transaction tree. It is still pending some other changes so I cannot provide a timeline for when this will be released atm. We don’t have any concrete plans to expose the full transaction stream in DAML Script atm but I had some vague thoughts about it in the past and if there’s a good usecase for it, it’s reasonable to add it.

Note that you can “fake” access to the transaction by calling query before and after the submit and looking at the delta. However, that only works for specific template types.

1 Like
3

Most of time my test cases only care about the result of the command, e.g. the exercise command results in contract ABC:1 archived and contract BCD:3 created.

Using query are good idea. Let me give it a go. Thanks. Just curious what kind of template support it?

1 Like
4

query supports all template types. What I mean by specific is that query only returns the contracts of one template so you can only answer the question “which contracts have been produced of this given template” rather than the more general “which contracts have been produced”. Of course, in a test case you usually can figure out all template types that might have been produced and you can call query once for each of them.

1 Like
5

Here’s a full example in case that’s useful:

module Main where

import Daml.Script

template T1
  with
    sig : Party
  where
    signatory sig
    preconsuming choice MakeMore : (ContractId T1, ContractId T2)
      controller sig
        do
          c1 <- create this
          c2 <- create T2 with sig
          return (c1, c2)

template T2
  with
    sig : Party
  where
    signatory sig

setup : Script ()
setup = script do
  alice <- allocatePartyWithHint "Alice" (PartyIdHint "Alice")

  c0 <- submit alice do createCmd T1 with sig = alice
  prev <- query @T1 alice

  (c1, c2) <- submit alice do exerciseCmd c0 MakeMore

  post <- query @T1 alice

  assert (c0 `elem` (map fst prev))
  assert (c0 `notElem` (map fst post))

What @cocreature meant is that, when you call query, you have to give it a type of template, and you only get the existing contracts for that one specific template. In the case of my example code above, prev and post only know about T1 contracts, but don’t contain any information about T2 contracts. So if you wanted to check multiple contract types, you’d need a separate call to query per template.

2 Likes
6

Thanks for the example. That helps a lot. :slight_smile:

1 Like