Category : 1.5

Release of DAML SDK 1.5.0

DAML SDK 1.5.0 has been released on September 16th 2020. You can install it using:

daml install latest

There are no changes requiring migration. However we do recommend using DAML Script in favor of Scenarios going forward. Learn more about Script in the notes below.

Interested in what’s happening in the DAML community and broader ecosystem? If so we’ve got a jam packed summary for you in our latest community update.

Highlights

  • DAML Script is now fully integrated into the IDE and will supersede Scenarios.

Impact and Migration

  • There are no changes requiring migration.
  • We recommend using DAML Script in favour of Scenarios for any new testing and scripting needs. It is more versatile and will supersede Scenarios.

What’s New

DAML Script in the IDE

Background

DAML Script was designed from the ground up to be “Scenarios 2.0”: A single scripting language for DAML for all use-cases. To make sure Scripts could be used truly universally, the first covered use-case was scripted interaction with live ledgers, introduced with SDK 0.13.55 in March 2020. DAML Repl and Triggers added interactive tooling and reactive automation. This latest release now completes the journey by providing the same real-time IDE integration that Scenarios have always offered, as well as adding a few more Script features that ease migration.

Scenarios offer functionality that cannot be offered via the Ledger API, which made it impossible to extend them into what DAML Script now is without breaking backwards compatibility. They are also in such widespread use that breaking backwards compatibility on Scenarios would have been costly. The two features will therefore live in parallel for a while, but Scenarios are going to be deprecated in an upcoming release, which means they may be removed with a major SDK version from 12 months after the date of deprecation and will not receive new features.

For more details on DAML Script and its role as “Scenarios 2.0”, please refer to our latest blog post.

Specific Changes

  • DAML Scripts are now run in DAML Studio just like scenarios. The functionality for inspecting the results is identical.
  • Add a script function to aid type inference. This is the equivalent of scenario.
  • In DAML Studio, you can now set the ledger time to the past. This is not supported when running against a ledger.
  • Add a queryContractId function for querying for a contract with the given identifier. This offers the Scenario functionality of submit p do fetch cid in a way that’s consistent with Ledger API use, but also allows for negative results by returning an Optional.
  • Add passTime helper to advance the time by the given interval.
  •  archiveCmd cid as a convenience wrapper around exerciseCmd cid Archive.

Impact and Migration

Given Scenarios’ widespread use and the fact that Script does not have complete feature parity with Scenarios, Scenarios will go through the proper deprecation cycle:

  1. They will be deprecated in an upcoming SDK version, and from SDK 2.0, the SDK will emit warnings on Scenario use.
  2. They may be removed from the next major SDK version 12 months from the time of deprecation.

Given DAML Script’s additional capabilities and the fact that Scenarios will not receive new features after deprecation, we recommend developing any new tests or initialization scripts using DAML Script instead of Scenarios.

If you would like to migrate existing Scenarios, please refer to the migration guide. If you are not sure how to migrate your Scenario to DAML Script, please get in touch with us.

Minor Improvements

  • You can now configure the application id submitted by DAML Script, REPL, and Triggers to the Ledger API using the  --application-id or --participant-config command line flags. This is needed if you are working against a ledger with authentication and need to match the application id in your token.
  • You can now convert DAML expressions to JSON in the DAML REPL using the meta-command :json. For example: :json [1, 2, 3]. This allows you to test how the JSON API would convert to JSON.
  • The maximum size for packages can now be configured independently in the JSON API. The  optional --package-max-inbound-message-size command line option sets the maximum inbound message size in bytes used for uploading and downloading package updates. It defaults to the max-inbound-message-size setting.
  • The DAML Standard Library has gained
    • a new function visibleByKey, together with improved  documentation on the authorization rules of the various byKey functions.
    • a Show instance for Ordering.
  • The @daml/react can now fetch a contractId using the useFetch hook.
  • The DAML Engine has had significant performance improvements:
    • foldl and foldr are each four times as fast as before
    • Record update expressions of the form R with f_1 = E_1; ...; f_n = E_n are much more efficient.
  • New docs pages giving further detail on the ordering guarantees DAML Ledgers give on events, and how the theory can be extended to span multiple infrastructures.

Early Access Development

  • DAML Trigger Service
    • Parties are now specified in request bodies as opposed to via HTTP Basic auth. This is done in preparation for running the trigger service against authenticated ledgers.
    • The database format has changed to allow migrations in future releases.  Databases are always initialized or migrated to the current version on start, so use of --init-db is no longer required. See issue #7092.
    • The --address option can be used to listen for HTTP connections on interfaces other than localhost, such as 0.0.0.0 for all addresses. See issue #7090.

Bugfixes

  • The fetch by key streaming endpoint (/v1/stream/fetch) of the JSON API had a bug where streaming multiple keys could silently ignore some of the given keys. This feature was not used by the @daml/* client libraries so you were only affected if you subscribed to the websocket endpoint directly.
  • The JSON API no longer returns offsets before the initial active contract set block. This matches the documented behavior that the first message containing an offset indicates the end of the ACS block.
  • The --application-id command-line option on the JSON API is now hidden and deprecated. The JSON API never used it as it uses Application ID specified in the JWT.
  • A bug in the Extractor that could cause transient contracts (created and archived within the same transaction) to be shown as active was fixed. See issue #7201 for details.
  • Calling the off method of the @daml/* client libraries’ event streams returned by streamQuery and streamFetchByKey now correctly remove the given listener.
  • The Scala bindings’ maxInboundMessageSize option in LedgerClientConfiguration was fixed. It previously only set the maximum size for the metadata. maxInboundMessageSize now does the correct thing, and a new option  maxInboundMetadataSize was added to set the maximum metadata size. These names match the Netty channel builder.
  • The Scala bindings’ client was sometimes not closed properly on application shutdown. You may have seen some RejectedExecutionException errors in your logs if this has affected you. This is now fixed, but we encourage all users of the LedgerClient to call the close method explicitly to ensure it is closed at an appropriate time in your application lifecycle.
  • withTimeProvider was removed from CommandClient in the Scala bindings. This method has done nothing since the new ledger time model was introduced in 1.0.0.  See issue #6985.

Integration Kit

  • When running the Ledger API Test Tool, the required DAR files are now uploaded to the ledger automatically before running the tests. You no longer need to upload these DARs before running the test tool.
  • kvutils now expects execution contexts to be passed into the various SubmissionValidator, LedgerStateAccess, and LedgerStateOperations methods. This is a source-breaking change. Instead of providing an execution context implicitly to your ledger implementation, you are encouraged to construct the relevant contexts for different operations explicitly. Please refer to the open-source implementations as a reference.
  • We have enriched the contextual information exposed by the Ledger API server. You should note richer logging information, which can be read either via unstructured or structured logging frameworks. A paragraph on how to configure structured logging has been added to the docs. For more on the issue, see issue #6837.

What’s Coming

We are continuing to work on performance of the DAML integration components and improving production readiness of DAML Ledgers, but there are exciting features and improvements in the pipeline for the next few releases as well.

  • The Trigger Service will reach feature completion and move into Beta
  • The authentication framework for DAML client applications (like the Trigger Service) is being revisited to make it more flexible (and secure!)
  • The build process for DAML client applications using the JavaScript/TypeScript tooling is being improved to remove the most common error scenarios
  • DAML’s error and execution semantics are being tidied up with a view towards improving exception handling in DAML
  • DAML will get a generic Map type as part of DAML-LF 1.9

Community Update – September 2020

As mentioned last month we’re turning our former announcement post into a community update. Below you’ll find everything our community has been up to over the past month.

Update: 1.5.0 has been released and you can read the full release notes here.

What’s New in the Ecosystem

Firstly we will be holding two community open door sessions for the 1.5.0 RC, one for US-based timezones and one for APAC. Register here for APAC/Europe morning timezones and here for US/Europe evening timezones. Both will be on September 14th so go signup! 📝

We might be a lot about DAML but we’re not *just* about DAML. Our biggest piece of news this month is that @cocreature just handed over maintenance of ghcide to the Haskell community, and they’re super-excited. This has major benefits for both Haskell and DAML as more maintainers will lead to more useful features in Haskell and DAML IDEs. Check out the rest of the details here. 👷‍♀️👷‍♂️

Our second Community Recognition Ceremony has kicked off. We do these quarterly to make sure our community members get the recognition they deserve for all of their wonderful contributions. Nominate who you think deserves to win here

György showing off the hoodie he won in the first Community Rewards Ceremony

Block8 just started a 4 part series comparing the upsides and downsides of DAML vs. Java on Corda. It’s a seriously explosive 🧨 review covering state, transactions, ease of development, testing, and functionality. 

@bartcant shows us how to use DAML to manage medical testing data while guarding patient’s privacy. 👩‍⚕️👨‍⚕️

@Shaul, our mostly fearless CTO, broke down how scaling works on DAML ledgers. 🚀

@gyorgybalazsi took a deep dive 🤿 into the DAML Finance library in the second post of his DAML master class. Covering big ideas like semantically rich identifiers, modularity, and multistep settlement chains. Few have explored the depths of the finance library like György has. György also found a bug 🐜 where Ordering didn’t have a Show instance, so now it does. Thanks!

We learned Exberry is using DAML and project:DABL to power ⚙️ the backend for their exchange infrastructure. Pretty cool.

@Amy_Ahmed , @andreolf@talia.klein@Felix_Kam@ManishGrover, and myself (@anthony) spent the last month mentoring students and participating at the hackbfs.com ideation-a-thon. It’s been a great experience being able to share our knowledge with the next generation of builders. 👨‍🏫👩‍🏫

@ManishGrover showed us how to improve customer experiences with smart contracts. 😁

And in case you missed it @dliakakos and @cocreature gave a webinar on what DAML Triggers are and how to write them. The full video 📹 is here.

Release Candidate for DAML SDK 1.5.0

The preliminary release notes and installation instructions for DAML SDK 1.5.0 RC can be found here.

1.5.0 RC Highlights

  • DAML Script is now fully integrated into the IDE and will supersede Scenarios.
  • Turn DAML expressions into JSON using the REPL (ex. :json [1, 2, 3]) which is useful for talking to the JSON API.
  • DAML on SQL now has much richer logging which means error messages will be a lot more transparent, allowing you to see exactly what call data caused an error. We’re also adding support for structured logs via Logstash Logback Encoder.
  • foldl and foldr performance has improved by 4x! 4x faster folds IN. ANY. DIRECTION. YOU. WANT.
  • Application IDs now work in DAML Script, Triggers, and REPL. Useful if you’re working with ledgers with authentication.
  • The Trigger Service can now bind to addresses other than localhost.
Script working in the DAML IDE just like Scenarios

What’s Coming

We are continuing to work on performance of the DAML integration components and improving production readiness of DAML Ledgers, but there are exciting features and improvements in the pipeline for the next few releases as well.

  • The Trigger Service will reach feature completion and move into Beta
  • The authentication framework for DAML client applications (like the Trigger Service) is being revisited to make it more flexible (and secure!)
  • The build process for DAML client applications using the JavaScript/TypeScript tooling is being improved to remove the most common error scenarios
  • DAML’s error and execution semantics are being tidied up with a view towards improving exception handling in DAML
  • DAML will get a generic Map type as part of DAML-LF 1.9