We really don’t need 600 lines of mostly deprecated and unmaintained
dependencies which get flagged by blackduck & dependabot if we can
inline this into a static array which we never changed since we first
added the docs.
changelog_begin
changelog_end
* Initial draft documentation for JSON API production recommendations
CHANGELOG_BEGIN
CHANGELOG_END
* changes based on draft review
* changes based on code-review
* more changes based on review comments
* add note on performance impact for rebuilding query store
* Minor tweaks.
* Use deduplication period instead of deduplication time.
* Introduced change ID and consistent use of deduplication duration/period.
* Consistent use of deduplication duration/period.
* Added ALREADY_EXISTS to the described gRPC errors.
* Minor tweak.
CHANGELOG_BEGIN
CHANGELOG_END
* Emphasize that applications should not change the deduplication time upon a resubmission
* Fix definition of change ID and always refer to it
* Try to clarify "Application-specific IDs"
* Make command deduplication explanation unspecific w.r.t. direction
Co-authored-by: Fabio Tudone <fabio.tudone@digitalasset.com>
* Update daml documentation to reflect the deprecation of the package/internal access token
CHANGELOG_BEGIN
CHANGELOG_END
* drop the whole internal access token section
* [docs] Replace AdoptOpenJDK suggestion by Adoptium
In the installation instructions, suggest Adoptium as JDK source
[AdoptOpenJDK has moved to the Eclipse foundation](
https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/)
* Without changelog entry
CHANGELOG_BEGIN
CHANGELOG_END
* [Divulgence pruning] Minor update to participant_pruning_service.proto divulgence docs
CHANGELOG_BEGIN
[Ledger API Specification] Participant pruning of all divulged contracts is fully implemented: Participant operators can choose to prune all immediately and retroactively divulged contracts, by setting the newly-added prune_all_divulged_contracts flag in the ParticipantPruningService/Prune request.
CHANGELOG_END
* Enrich `Daml Participant Pruning` in the `Operating Daml` docs section
* Apply suggestions from code review
Co-authored-by: mziolekda <marcin.ziolek@digitalasset.com>
Co-authored-by: mziolekda <marcin.ziolek@digitalasset.com>
* [Docs] Add info on logs on Kubernetes & metrics in the ops section
changelog_begin
- [Docs] Information was added in the `Operating Daml` section on how to aggregate logs on Kubernetes in conjuction with Daml services & what options exists for exporting metrics from daml services (not Kubernetes specific)
changelog_end
* Move the new docs into a seperate section 'Operating Daml Connect'
* Move section again, now it's a subsection under Operating Daml
* Update docs/source/ops/connect/content.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Apply suggestions from code review
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* Rename file
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* rewrite trigger docs to follow gsg
Per #10419 point 4, I've rewritten the Triggers section to build upon
the Getting Started Guide instead of inventing its own example.
Compared to #10395, this has a lot more explanations as this page must
now serve the dual purpose of being a possible "next step" from the GSG
and being the main reference page for triggers. It's also lost the "next
steps" section, which I think is a bit of a shame, but it doesn't really
make sense here.
There's also no easy way for people not interested in the GSG to follow
along; should we expose the "completed GSG" as a tempate?
CHANGELOG_BEGIN
CHANGELOG_END
* keep copy-trigger as a template
* fix copy-trigger project name
* make up gsg-trigger template
* remove awkward sentence, fix existing typo
* update code to use when{,Some}
* add to
* swap emitCommands and getCommandsInFlight
* typo
* insist on state-correction perspective
* fix copy-trigger tests
* add back copy-trigger to whitelist
* add gsg-trigger to whitelist
* Add test-case to ConfigSpec for output type
changelog_begin
changelog_end
* Add an --all-parties flag to ledger export
changelog_begin
* [Daml export] You can now set the ``--all-parties`` option to generate
a ledger export as seen by all known parties.
changelog_end
* Update docs
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* correct JSON API upper date bound
As reported by @quid-agis. Fixes#10449.
CHANGELOG_BEGIN
CHANGELOG_END
* add tests
* test error messages
* more specific catch
changelog_begin
- [Docs] The manual install instructions now use a different gpg keyserver because the old one is deprecated / not reachable anymore
changelog_end
Previously data-dependencies in the generated daml.yaml file had a path
including the output-dir path itself. E.g.
```
data-dependencies:
- /some/out/path/deps/some.dalf
```
This worked fine so long as the output path was absolute. However, if
the output path is a relative path, then it might lead to "no such file"
errors during daml build.
This change always makes the generated data-dependencies paths relative
to the daml.yaml file.
changelog_begin
- [Daml export] The generated paths to data-dependencies DALFs are now
relative to the generated daml.yaml. Fixes
https://github.com/digital-asset/daml/issues/10378.
changelog_end
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
The current entry has been moved from "open-source integrations" to
"commercial integrations" in 73b38f8add. However, the move was done
verbatim, while the format for the two tables is different, making the
Besu listing stick out a bit. Moreover, since the listing was added the
URL of the press release has changed, landing people on the front page
of the DA blog (from which it is possible to find the relevant press
release, but quite frankly googling for it is faster).
For the record, I still think this page should be hosted elsewhere as
the docs release cycle doesn't offer enough dynamism for it.
CHANGELOG_BEGIN
CHANGELOG_END
* [DOCS] Add documentation for the JSON API metrics
changelog_begin
- [JSON-API] You can now find a section `Metrics` in the http-json api documentation explaining how to enable metrics and which are available
changelog_end
* Fix rst build warnings
* Update docs/source/json-api/metrics.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Adapt metrics doc to state that it IS an exhaustive list and remove wrong copy pasta text & add info about prometheus
* Update the legal values for the metrics reporter cli option
* shorten the description, the change prior was unnecessary ._.
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Nobody reported any issues and we’re not planning breaking changes so
ship it!
changelog_begin
- [Daml Profiler] The Daml profiler is now a stable feature.
changelog_end
* Improvements to the documentation with regards to offsets
changelog_begin
[Docs] Improvements to the documentation with regards to offsets
changelog_end
- Simplify wording to explain the usage of `blockingForEach` in the Java
bindings quickstart page
- Describe offsets in prose in the page about the Ledger API services
- Suggest how to perform crash recovery with offsets on the application
architecture page
- Link to the relevant Protobuf reference docs where approriate
* Apply suggestions from code review
Thanks @cocreature
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Addresses https://github.com/digital-asset/daml/pull/10180#discussion_r664001785
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Downloading and running the JAR manually is so 2019.
changelog_begin
[Docs] Document how to use the Java codegen using the Daml assistant
changelog_end
Fixes#8817
* Ledger API: bump version for LF 1.14
CHANGELOG_BEGIN
* Ledger API: bump version for LF1.14
CHANGELOG_END
* Update docs/source/support/compatibility.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/support/compatibility.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Java bindings: add DamlRecord, deprecate Record
Fixes#10130
changelog_begin
[Java bindings] In order to avoid clashing with `java.lang.Record` (introduced
in Java 14), `com.daml.ledger.javaapi.data.Record` has been renamed to
`com.daml.ledger.javaapi.data.DamlRecord`. The old name has been used to
denote a sub-type of the newly renamed one, so it can still be used, but it has
been marked as deprecated.
[Java codegen] The Java codegen now uses the `DamlRecord` type wherever `Record`
was used before.
changelog_end
Boy-scout rule:
- removed references to ~old~ ancient versioning
- used `@deprecated` Javadoc annotation wherever meaningful
- some import re-arrangement performed by the linter
* Address https://github.com/digital-asset/daml/pull/10132#discussion_r659705929
Since per-request offset can be described strictly as a special case of the new
per-query offset semantics, go ahead and describe it that way, so that really
only one model needs to be understood to fully comprehend the query request
semantics.
CHANGELOG_BEGIN
CHANGELOG_END
changelog_begin
- [Ledger API] Use of divulged contracts in later transactions is
deprecated. Divulged contracts were already incompatible with
pruning. We are working on features to handle the cases currently
covered by divulgence.
changelog_end
