canton-network-docs
Values in the Ledger API
Values in the Ledger API - Canton Network Docs
Skip to main content
Assume another package called
Then the ledger API will accept Create commands for
This is because the module and type names of the type annotation,
Then submitting a Create command for
Submitting the same command but with no label for field
However, providing all but the trailing optional field
Also assume a ledger that contains a contract of type
Then querying the ledger’s active contract set in non-verbose mode returns the following:
Note that not only has the third template argument (originally
Commands and queries have relaxed validation rules for ingested values. Returned values are subject to normalization.Documentation Index
Fetch the complete documentation index at: https://docs.canton.network/llms.txt
Use this file to discover all available pages before exploring further.
Value Validation in Commands
In the following examples, the target template of a command is the template or interface identified by thetemplate_id field of the command after dynamic package resolution.
A value featured in a command (e.g. create_arguments) has expected type T if the value needs to type-check against T in order to satisfy the type signatures of the target template of the command. Note that this definition necessarily extends to sub-values.
In a record value of the form Constructor { field1 = v1, ..., fieldn = vn }, vi is a trailing None if for all n >= j >= i, vj = None.
On submission of a command, the validation rules for values are relaxed as follows:
These rules apply for all sub-values. Example 1 Assume a package called
- The
record_id,variant_id, andenum_idfields of values, if present, are only checked against the module and type name of the expected type for that value. The package ID component of these fields is ignored.- In record values where all field names are provided, any fields of value None may be omitted.
- In record values where not all field names are provided, fields must be provided in the same order as that of the record type definition, and trailing Nones may be omitted.
example1-1.0.0 which defines a template called T in a module called Main.
other-1.0.0 which defines a different template also called T in a module also called Main.
example1-1.0.0:Main.T whose create arguments are annotated with type other-1.0.0:T:Main.T, even though the type annotation is wrong. In other words, the following console commands succeed:
Main and T, match those of the expected type: example1-1.0.0:Main.T.
Example 2
Assume a package called example2-1.0.0 which defines a template with two optional fields: one in leading position, and one in trailing position.
example2-1.0.0:Main.T which only provides p by name and no other field succeeds:
p fails:
j suceeds, even without labels:
Value normalization in Ledger API responses
A Ledger API value (e.g.create_arguments in a CreatedEvent) is said to be in normal form if none of its sub-values (itself included) has trailing Nones.
Starting with Daml 3.3.0, values in Ledger API non-verbose responses are subject to normalization. The normalization extends to all sub-values.
Example
Assume a package called example1-1.0.0 which defines a template T and a record Record in a module called Main.
T written by example1-1.0.0 where all the optional fields are set to None.
j) been omitted from the response, but also the third field of the nested record (originally rk). Note also that despite being optional fields of value None, the second template argument (originally i) and the first nested record field (originally ri) are present in the response because they are not in trailing positions.