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.
--implicit-party-allocation=No
flag.
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.
Background
This change addresses several gaps in the API coverage of DAML Connect tooling. In particular, it adds support for the party and package management APIs to the JavaScript Client libraries, easing the development of client applications that perform administrative tasks.
Specific Changes
Ledger
object, returned by useLedger
, now has three new methods covering the package management API, and three new methods covering the party management API:
listPackages
returns a list of all known packageIDs,getPackage
returns the binary data of the corresponding DALF, anduploadDarFile
takes binary data and uploads it to the ledger. Note that uploadDarFile
requires admin access.getParties
allows 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,listKnownParties
will return a list of all known parties, and allocateParty
will allocate a new party.Ledger
object now also exposes the API method createAndExercise
, which creates a contract and exercises a choice on it in the same transaction.daml ledger
can now also be run against the JSON API instead of the gRPC API.listKnownParties
function in DAML Script is now also supported when running over the JSON API.
Impact and Migration
This change is fully backwards compatible.
Background
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/.
Specific Changes
--implicit-party-allocation
option, previously enabled by default, is no longer supported by DAML for PostgreSQL.--sql-backend-jdbcurl-env
. For example, to instruct the DAML Driver to read the PostgreSQL JDBC URL from JDBC_URL
, use --sql-backend-jdbcurl-env "JDBC_URL"
.--sql-backend-jdbcurl
flag 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.
/v1/fetch
endpoint 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/fetch
is also significantly more efficient for large datasets, though still linear.password
option in the config file is now deprecated. Note that the option has not had an effect since SDK 1.0.0.docker trust inspect
command. You can also set the DOCKER_CONTENT_TRUST
environment 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 --pretty
and then pin the image hash rather than relying on tags.docker sign inspect
command should mention a signer named automation
with a public key ID matching 533a6e09faa512f974f217668580da1ceb6aa5b00aad34ea1240afc7d249703f
(note that the --pretty
output only shows the first 12 chars) and a repository key matching f5dc2aee6aed2d05d7eda75db7aa2b3fac7fc67afbb880d03535d5a5295a0d3b
.
--target=1.dev
to your daml.yaml
, but note that packages compiled to DAML-LF 1.dev cannot be deployed to production ledgers.observer
to the 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 : ()
with
message: Text
sender: Party
receivers: [Party]
observer receivers
controller sender
do
return ()
sender
will all see an exercise node of type MyEvent
with a payload containing message
.applicationId
in the start request.New endpoint | Old endpoint | Functionality |
---|---|---|
GET /v1/triggers |
/v1/list |
List triggers |
POST /v1/triggers |
/v1/start |
Start trigger |
GET /v1/triggers/:id |
/v1/status/:id |
Trigger status |
DELETE /v1/triggers/:id |
/v1/triggers/:id |
Stop/delete trigger |
POST /v1/packages |
/v1/upload_dar |
Upload DAR |
GET /livez |
/v1/health |
liveness check |
--port-file
option matching the corresponding option in the JSON API.--dar
options.Daml.Trigger
module now re-exports Event
which avoids having to import Daml.Trigger.LowLevel
for implementing a non-trivial updateState
function.
let
expressions with multiple bindings. This fixes a bug where let
expressions would be evaluated in the wrong order.
ParticipantPruningService
enables 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:
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.