Daml Connect 1.8.0 has been released on December 16th. You can install it using:
daml install 1.8.1
Note: Daml Connect 1.8.0 contained a bug that is now fixed and noted in the 1.8.1 release. Daml Connect 1.8.0 is no longer supported.
Want to know what’s happening in our developer community? Check out the latest massive update for this month.
- Daml Driver for PostgreSQL Community Edition is now stable.
- Action required unless you were already using the
- Running the Sandbox with persistence is now deprecated.
- Action required unless you were already using the
Impact and Migration
The Daml compiler now enforces sequential ordering for let expressions with multiple bindings. This fixes a bug where let expressions would be evaluated in the wrong order. In rare cases it may be necessary to re-order your let expressions if they relied on forward references.
In the old behavior the code below would rely on forward references and result in `x` being assigned the value `1` despite `y` being assigned this value after `x`. In the fix this is now a compile-time error.
let x = y y = 1 in x
To correct this code you would change the order of the assignments so:
let y = 1 x = y in x
There are no other backwards incompatible changes to any stable components.
Daml Driver for PostgreSQL (daml-on-sql) Community Edition ledger has been downloadable as Early Access from GitHub releases since SDK 1.4.0. The option
--implicit-party-allocation used to be on by default, but has now been removed. Users that were using the Daml Driver for PostgreSQL with the implicit party allocation option will need to explicitly allocate parties now.
Users running Daml Triggers (Early Access) against authenticated ledgers may now need to handle authentication errors externally.
Better API coverage in Script, Libraries, and Assistant
Ledgerobject, returned by
useLedger, now has three new methods covering the package management API, and three new methods covering the party management API:
listPackagesreturns a list of all known packageIDs,
getPackagereturns the binary data of the corresponding DALF, and
uploadDarFiletakes binary data and uploads it to the ledger. Note that
uploadDarFilerequires admin access.
getPartiesallows users to, based on a party id (or party ids, as the name suggests) fetch more information about the party or check for its existence,
listKnownPartieswill return a list of all known parties, and
allocatePartywill allocate a new party.
Ledgerobject now also exposes the API method
createAndExercise, which creates a contract and exercises a choice on it in the same transaction.
daml ledgercan now also be run against the JSON API instead of the gRPC API.
listKnownPartiesfunction in Daml Script is now also supported when running over the JSON API.
Impact and Migration
This change is fully backwards compatible.
Daml Driver for PostgreSQL Community Edition now stable
Daml Driver for PostgreSQL (daml-on-sql) Community Edition ledger has been downloadable as Early Access from GitHub releases since SDK 1.4.0. With release 1.8.0 it is now stable and completes the separation of the Sandbox development and test tool from a SQL-based ledger intended for production use. Accordingly, as announced in the release notes of SDK 1.4.0, the persistence mode in Sandbox is now deprecated.
Documentation is available at https://docs.daml.com/daml-driver-for-postgresql/.
--implicit-party-allocationoption, previously enabled by default, is no longer supported by Daml for PostgreSQL.
- The PostgreSQL JDBC URL can now be passed in through an environment variable via
--sql-backend-jdbcurl-env. For example, to instruct the Daml Driver to read the PostgreSQL JDBC URL from
- The feature to run Sandbox with persistence using the
--sql-backend-jdbcurlflag is now deprecated.
Impact and Migration
Anyone wanting to run an open source Daml ledger on SQL is advised to migrate to Daml Driver for PostgreSQL. SQL support in Sandbox may be removed with a major version release following the usual 12-month deprecation cycle.
Implicit party allocation was previously the default mode of operation in Daml Driver for PostgreSQL. Users of Daml Driver for PostgreSQL should now allocate parties explicitly using the admin endpoints of the JSON or gRPC APIs. The combination of persistence and implicit party allocation will not be supported after the deprecation cycle; implicit party allocation will continue to be supported in Sandbox.
- The JSON API’s
/v1/fetchendpoint now uses the Postgres database, if configured, to look up contracts by ID or key, except when querying a contract by ID without its corresponding template ID. The fallback in-memory version of
/v1/fetchis also significantly more efficient for large datasets, though still linear.
You may optionally re-create the JSON API database to take full advantage of this change. See issue #7993.
- The Navigator’s
passwordoption in the config file is now deprecated. Note that the option has not had an effect since SDK 1.0.0.
- If no parties are in the Navigator config or daml.yaml, Navigator will now pick up parties from the party management service. Those parties are periodically refreshed.
- The SDK Docker image is now signed. Note that this is a dev-only image, not intended for production use.
To verify the signature, use the
docker trust inspectcommand. You can also set the
DOCKER_CONTENT_TRUSTenvironment variable to 1 to instruct Docker commands to only pull and run signed images. Keep in mind, however, that this only checks that there is a signature, not that the signer is who you expect it to be. For optimal security, you should manually check the signature once with
docker trust inspect --prettyand then pin the image hash rather than relying on tags.
The expected output of the
docker sign inspectcommand should mention a signer named
automationwith a public key ID matching
533a6e09faa512f974f217668580da1ceb6aa5b00aad34ea1240afc7d249703f(note that the
--prettyoutput only shows the first 12 chars) and a repository key matching
- The gRPC Ledger API proto definitions and documentation pages now document the error codes endpoints may return.
- Daml-LF protobuf definitions are now published to Maven Central in JARs. The artifact names follow the format “<name>_proto_jar” under group “com.daml”.
- The *.proto files containing the gRPC definitions are now provided by a new Maven Central artifact, with the group “com.daml” and the artifact name “ledger-api-proto”.
Early Access Features
- Support choice observers in Daml-LF 1.dev. Daml-LF 1.dev can be activated by adding the build option
daml.yaml, but note that packages compiled to Daml-LF 1.dev cannot be deployed to production ledgers.
Choice observers, documented on the reference page for choices, add an additional keyword
choice …syntax. Parties designated choice observers using that keyword are guaranteed to see the exercise of the choice. This can be useful for defining custom events, for example.
nonconsuming choice MyEvent : ()
Here the parties in
senderwill all see an exercise node of type
MyEventwith a payload containing
- Trigger Service
- Fixed a bug where complex models resulted in a fatal error when restoring the state from the database due to an incorrect protobuf recursion limit.
- The application id used by a trigger can now be configured by an optional
applicationIdin the start request.
- The trigger status endpoint /v1/triggers/:id now includes metadata about the trigger like the party and the trigger id. The logs field has been replaced by a status field.
- Endpoints have been rearranged to be more consistent:
New endpoint Old endpoint Functionality GET
List triggers POST
Start trigger GET
Trigger status DELETE
Stop/delete trigger POST
Upload DAR GET
- The trigger service now has a
--port-fileoption matching the corresponding option in the JSON API.
- The trigger service now accepts multiple
Daml.Triggermodule now re-exports
Eventwhich avoids having to import
Daml.Trigger.LowLevelfor implementing a non-trivial
- UNAUTHENTICATED errors will now terminate the trigger. These errors are no longer available for handling in the trigger Daml code. Instead, they are forwarded to the trigger service for handling, e.g., access token refresh.
- Command submission requests to the gRPC Ledger API now accept some optional fields for use in the upcoming multi-party submissions feature. Such submissions currently return UNIMPLEMENTED errors, but they will be enabled in the future.
- The Daml compiler now enforces sequential ordering for
letexpressions with multiple bindings. This fixes a bug where
letexpressions would be evaluated in the wrong order.
- Fixed a bug where trace statements from a failing transaction were not displayed in Daml Studio.
- Fixed a regression in the HTTP JSON API introduced in SDK 1.7.0, where using a party multiple times in the same JWT token (e.g., readAs and actAs) broke database queries for that party. Note that there is never a reason to include a party multiple times since actAs implies readAs.
- When using a PostgreSQL-based index, leveraging native parallel unnesting allows you to more efficiently index new transactions.
- The kvutils Protobuf definition is now published to Maven Central in a JAR, under the group “com.daml”, with the artifact name “participant-state-kvutils-proto”.
- The Scala JARs containing the gRPC definitions no longer contain the *.proto files used to generate the ScalaPB-based classes.
- New CLI option –cert-revocation-checking for enabling the TLS certificate revocation checking in the LedgerApiServer.
- kvutils reports LookupByKey node mismatches during validation as Inconsistent instead of Disputed if they can be due to contention on the contract key.
- Bugfix: daml.index.db.store_transaction metrics were keeping track of empty insertions, skewing down the numbers.
- Performance: minimizing the number of traversals of a transaction to index it, more efficient indexing.
- The integrity checker now validates the contents of each write set, regardless of whether it is used subsequently.
- Pipelining in the indexing process improves throughput by up to 15%.
- Correct some remaining package name references to com.digitalasset.platform in logback and readme file.
- Fix a bug resulting in the error message “Dispatcher is closed” on participant shutdown (#7986).
- The preview of
ParticipantPruningServiceenables ledger participants to prune the “front” of ledger state at the participant including the ledger api server index.
The eagle eyed reader may have noticed that some features have appeared in the “What’s Next” section for some time, and that there hasn’t been a Daml-LF release since SDK 1.0.0 and Daml-LF 1.8. This will change with one of the next releases because several features that require a new Daml-LF version are currently being finalized:
- Choice observers (see Early Access section above)
- Generic Maps
- Better Exception Handling in Daml
Work also continues to move Daml Triggers and the Trigger Service (see Early Access section above) to general availability.
Lastly, the multi-party read features on the gRPC Ledger and JSON APIs will be supplemented with multi-party writes, allowing the submission of commands involving multiple parties via the APIs as long as they are all hosted on the same node.