Daml SDK 1.3.0 has been released 16th July 2020. You can install it using
daml install latest
This is a purely additive upgrade which comes with new features, functionality, and bug fixes. Upgrading should not require any intervention.
The Daml Studio VSCode extension is affected by a known and recently fixed bug in recent VSCode versions: https://github.com/microsoft/vscode/issues/89038
For some users this may lead to the Scenario View in VSCode not rendering correctly. If you are affected by this issue upgrading to VSCode 1.47 should resolve it.
Background
The JSON API Server exposes several Websocket endpoints which allow clients to maintain a live view of contract data without polling. These endpoints have been available since before SDK 1.0 in early access, and are now considered stable.
Specific Changes
/v1/stream/query
and /v1/stream/fetch
endpoints are finalized and fully implemented.
Impact and Migration
The final version of these endpoints is backwards compatible with SDK 1.0 in the sense that clients of these endpoints from SDK 1.0 work with SDK 1.3. Thus no action needs to be taken.
Background
The JSON API Server is a component intended to be run in production environments to supplement the lower level Ledger API with an easy-to-use queryable ledger state consumable by any HTTP 1.1 client, including web browsers. Despite this intended use case, the JSON API Server was only distributed as part of the SDK, which meant that the Daml SDK had to be installed on production servers in order to run the JSON API Server. Providing a stand-alone JAR distribution gives application operators a much leaner deployment option.
Specific Changes
Impact and Migration
This is purely additive to the distribution via the SDK so no action is needed. However, if you do run the JSON API Server in a test or production environment, this gives you a leaner and more portable way of doing so.
Background
Daml Script and REPL had some limitations in key test and production use cases. Firstly, neither exposed the Time Service, which made them hard to use in static time mode. Secondly, they only exposed functions to allocate parties, not to query existing parties, which required existing parties to be passed in via a file, or to be obtained using unsafe functions like partyFromText
. By exposing the relevant functions of the Ledger API in Daml Script and REPL, Ledger Time can now be queried and set in Static Time mode, and existing parties can be queried.
In addition, it is now possible to use Daml Script and REPL with multiple JWTs, which in particular, means they can be used with multiple parties on DABL.
Specific Changes
getTime
now correctly handles time changes in static time mode and returns the current time by querying the time service rather than defaulting to the Unix epoch.getTime
continues to return the system time in UTC. When run against the JSON API in static time mode, it continues returning Unix epoch.setTime
to Daml Script and REPL which sets the ledger time via the Ledger API time service.listKnownParties
and listKnownPartiesOn
to query the corresponding ListKnownParties endpoint in the Party Management service.--static-time
and --wall-clock-time
flags.--participant-config
in a new access_token
field. The existing --access-token-file
flag is still supported if you want to use the same token for all connections. See https://docs.daml.com/daml-script/index.html#running-daml-script-against-authenticated-ledgers for more details.
Impact and Migration
This functionality is purely additive so no action needs to be taken.
Background
Daml Studio’s Scenario view allows developers to explore the transactions resulting from their Daml models in real time. One of the main uses of doing so is to verify that privacy is preserved as expected. Until now, the available views only gave information on who got to see a contract and through which transaction. SDK 1.3 adds information on the mechanism through which a party learned about a contract. This saves the developer the work of inferring this from the detailed transaction view.
Specific Changes
S
means the party is a signatory.O
means the party is an observer.W
means the party has witnessed the creation of the contract.D
means the party has learned about the contract via divulgence.
Impact and Migration
This functionality is purely additive so no action needs to be taken.
Background
Daml Triggers give developers the ability to write automation of Daml applications in the style of database triggers using the Daml language itself, aiding code reuse and allowing contract definitions and basic automation to be packaged and shipped together. These triggers need to be managed at runtime, which until now required developers to manage individual JVM processes, raising the bar to actually deploying Daml Triggers in production. The Trigger Service provides a way to manage Daml Triggers via a simple REST API.
The Trigger Service is currently in Alpha, meaning API changes are still likely, and it notably doesn’t support authentication yet.
Specific Changes
daml trigger-service
command to the SDK to start the Trigger Service. More information in the documentation.
Impact and Migration
This functionality is purely additive so no action needs to be taken. If you are already evaluating Triggers for your application, we highly recommend trying out the Trigger Service as it should ease their use considerably. We welcome your feedback.
Bot.wire
and Bot.wireSimple
now return a Disposable
, which can be used to shut down the flows. You are encouraged to call .dispose()
before terminating the client.--max-ledger-time-skew
flag.daml sandbox --help
for details.useQuery
, useFetchByKey
and their streaming variants with true
. This removes a glitch where the loading indicator was false
for a very brief moment when components using these hooks were mounted although no data had been loaded yet. Code using these hooks does not need to be adapted in response to this change.REACT_APP_HTTP_JSON_PORT
damlc test --project-root
now works with relative paths as well.ListKnownParties
response's PartyDetails
now properly reflects where a party is non-local on distributed, multi-participant ledgers that expose parties to remote participants.port
was ignored for non-empty paths in the url when running Daml Script over the JSON API.
--exclude
and --include
flags now match the full test name as a prefix, rather than just suite names. Test name is built by combining the suite name with a test identifier, so this change should be fully backwards compatible. Run with --list-all
to list all tests (as opposed to just the test suites with --list
).lfValueTranslationEventCache
and lfValueTranslationContractCache
2
rather than 1
. This would not affect most users of Sandbox or other kvutils-based ledgers, as if a configuration is set automatically on startup when creating a new ledger. This affects users who explicitly override the initial ledger configuration submit delay to something longer than a few milliseconds.daml.index.db.store_ledger_entry
.
daml.index.db.store_ledger_entry.prepare_batches
: measures the time for preparing batch insert/delete statementsdaml.index.db.store_ledger_entry.events_batch
: measures the time for inserting eventsdaml.index.db.store_ledger_entry.delete_contract_witnesses_batch
: measures the time for deleting contract witnessesdaml.index.db.store_ledger_entry.delete_contracts_batch
: measures the time for deleting contractsdaml.index.db.store_ledger_entry.insert_contracts_batch
: measures the time for inserting contractsdaml.index.db.store_ledger_entry.insert_contract_witnesses_batch
: measures the time for inserting contract witnessesdaml.index.db.store_ledger_entry.insert_completion
: measures the time for inserting the completiondaml.index.db.store_ledger_entry.update_ledger_end
: measures the time for updating the ledger enddaml.execution.total
daml.execution.lookup_active_contract_per_execution
: measures the accumulated time spent for looking up active contracts per executiondaml.execution.lookup_active_contract_count_per_execution
: measures the number of active contract lookups per executiondaml.execution.lookup_contract_key_per_execution
: measures the accumulated time spent for looking up contract keys per executiondaml.execution.lookup_contract_key_count_per_execution
: measures the number of contract key lookups per execution
Most of our current work is going into performance of the Daml integration components and improving production readiness of Daml Ledgers. In parallel, we are putting finishing touches on the feature work we’ve started on: