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.