Skip to content
Digital Asset Logo

Release of Daml Connect 1.11.0

| |

Daml Connect 1.11.0 has been released on Wednesday March 10th. You can install it using:

daml install latest

Want to know what's happening in our developer community? Check out the latest update for this month.

Highlight

  • Daml Ledger API 1.10 with Daml-LF 1.12 is now stable, significantly reducing the size of Daml transactions.
  • Daml-LF 1.11 is now the default. The previous default was Daml-LF 1.8.
  • daml test now includes coverage output so you can easily see which Templates and Choices are tested.
  • Daml Studio will now provide the last working state before a failed transaction, greatly streamlining debugging a broken transaction.
  • Daml Driver for PostgreSQL now has a separate migration mode and a configurable DB connection pool.

Impact and Migration

The only impact of this release is that with the switch from Daml-LF 1.8 to Daml-LF 1.11, the “no” contract-id-seeding mode in Sandbox Classic is no longer available by default. As already indicated in the Daml Connect 1.10 release notes, users must either pin the Daml-LF version to Daml-LF 1.8, or explicitly choose a new seeding mode. The recommended mode is “strong”.

What’s New

New Daml-LF and Ledger API Versions

Background

Daml-LF is Daml’s intermediary language, analogous to Java bytecode. With Daml Connect 1.11, Daml-LF 1.12 is now stable and frozen, and Daml-LF 1.11 is the new default version. Daml-LF 1.12 is supported by Daml Ledger API 1.10 upwards. The changes in Daml-LF 1.12 are non-functional. Significantly smaller transaction sizes on the wire and in storage provide performance improvements.

Daml-LF 1.12 will become the new default version with the April 2021 Daml Connect release. Until then, you can enable Daml-LF 1.12 in your daml.yaml file by adding the stanza:

build-options:

  - --target=1.12

Specific Changes

  • Daml-LF 1.12 is now stable
  • Daml-LF 1.11 is now the default version (previously Daml-LF 1.8)
  • Daml Connect and integration kit now expose Daml Ledger API 1.10

Impact and Migration

Sandbox Classic’s default contract seeding mode no is not compatible with Daml-LF 1.11. If you use Sandbox Classic, you need to either pin the Daml-LF version to <= 1.8 or switch contract seeding mode. If you do neither, Sandbox Classic will present you with an error informing you that you need to do one or the other. 

We recommend doing one of the following:

If you are relying on the human-readable, stable contract-ids for demo purposes, pin the Daml-LF version by adding this stanza to your daml.yaml:

build-options:

  - --target=1.8

If you would like Sandbox Classic to resemble production ledgers more closely, switch contract id seeding mode by adding:

sandbox-options:

  - --contract-id-seeding=strong

Test Coverage in Command Line Test Tooling

Background

The daml test command runs all Daml Scripts (and Scenarios) in a Daml project and reports their results. A common feature request has been to also report on test coverage and allow the inclusion of tests in dependencies, thus offering better support for multi-package projects. The new features provide both of these capabilities.

Specific Changes

  • The daml test command has gained a flag --all, which includes scripts and scenarios from dependencies in the list of tests being run.
  • The daml test command has gained a flag --show-coverage, which shows a test coverage report.

    For example:

daml/User.daml:test: ok, 2 active contracts, 3 transactions.

test coverage: templates 50%, choices 50%

templates never created:

User:MyTemplate

choices never executed:

User:MyTemplate:Archive

User:MyTemplate:MyChoice

Impact and Migration

This is a purely additive change.

More information for failing Scripts in Daml Studio

Background

Successful Daml Script executions in Daml Studio show a tabular view of the final ledger state by default. With this change, that view is now also available for failed executions, making debugging a failure easier.

Specific Changes

  • The view of a failed script in Daml Studio now allows switching to table view, which looks like this:

Impact and Migration

This is a purely additive change.

Improved database management in Daml Driver for PostgreSQL

Background

The Daml Driver for PostgreSQL has gained two new features that make it easier and safer to operate in a production environment.

Specific Changes

  • All functions that require database schema changes have been separated into a special “migrate” mode. This way the driver can use a less privileged database user account in normal operation. The migrate mode is enabled via flag --sql-start-mode migrate-only. See the documentation for full details. 
  • The database connection pool size is now configurable to prevent the driver from establishing too many connections at once. This is done via the --database-connection-pool-size flag.

Minor Improvements

  • You can now disable linter (dlint) hints for a specific function by adding pragmas of the form {- DLINT ignore functionName "hintName" -} to your Daml source files. For example:

{- DLINT ignore noHint "Use concatMap" -}
noHint f xs = concat (map f xs)

  • More logging of Ledger API activity
    • Incoming requests to API services are now logged at INFO level. Note that this is the default log level for the Sandbox. To emit these from the Sandbox, add the sandbox option --log-level=INFO. A sample message is

17:06:27.099 &#91;sandbox-akka.actor.default-dispatcher-4] INFO c.d.p.a.s.ApiSubmissionService - Submitting transaction (context: {readAs=&#91;], submittedAt=2021-03-03T16:06:27.093385Z, applicationId=myproject, deduplicateUntil=2021-03-04T16:06:27.093385Z, actAs=&#91;Alice], commandId=91f433da-daae-49d3-9336-783b86956a60})

  • Transactions and transaction trees returned by the TransactionService are now logged at DEBUG level. To emit these from the Sandbox, add the sandbox option --log-level=DEBUG. A sample message is

17:11:35.771 &#91;sandbox-akka.actor.default-dispatcher-9] DEBUG c.d.p.a.s.t.ApiTransactionService - Responding with transactions: List(Map(commandId -&gt; 8863aaac-3597-4001-b839-e1813f4576ba, transactionId -&gt; 0A2439343435613763382D316665352D333635382D383933612D393033373966313763353231, workflowId -&gt; , offset -&gt; 00000000000000070000000000000000)) (context: {startExclusive=00000000000000050000000000000000, endInclusive=, parties=&#91;Alice]})

  • Scala Ledger API Bindings and Codegen output are now also available for Scala 2.13. Note that the Scala Ledger API Bindings and Codegen are deprecated.

Bugfixes

  • A bug preventing the Scala Codegen from working when there are any Daml packages called Set was fixed. See #8854 for details.
  • A JWT token is no longer required to call methods of Health and Reflection services.

Integration Kit

  • Upgrade dependency io.opentelemetry:opentelemetry-api to 0.16.0
  • New dependency: io.opentelemetry:opentelemetry-context:0.16.0
  • The various uses of ByteString in kvutils are now strongly typed. Users of kvutils will need to use the Raw.Bytes subtypes to represent the various keys and values that flow through a kvutils-based driver. ByteStrings representing keys need to be wrapped in either Raw.LogEntryId or Raw.StateKey, and ByteStrings representing value envelopes need to be wrapped in Raw.Envelope. This prevents accidentally confusing one for the other. Implicit conversions have been provided for Scala users, which should  ease the transition. They are marked @deprecated and will be removed before the release of Daml SDK v1.12.
  • Added the CLI options api-server-connection-pool-size and indexer-server-connection-pool-size to configure the database connection pool size for the Ledger API Server and the indexer respectively.
  • Fix potential out of memory issue when running migrations on an existing index DB with many events/contracts/transactions.

What’s Next

  • Despite the order of magnitude performance improvements we have already accomplished, this continues to be one of our top priorities. 
  • Improved exception handling in Daml is progressing well and expected to land in one of the next Daml-LF versions.
  • We are continuing work on several features for the Enterprise Edition of Daml Connect:
    • A profiler for Daml, helping developers write highly performant Daml code.
    • A mechanism to verify cryptographic signatures on commands submitted to the Ledger API, improving security in deployment topologies where the Ledger API is provided as a service.
    • Oracle DB support throughout the Daml Connect stack in addition to the current PostgreSQL support.
  • A new primitive data type in Daml that allows infinite precision arithmetic. This will make it much easier to perform accurate numeric tasks in Daml.

Related Posts