diff --git a/versioned_docs/version-3.8/backup-restore.mdx b/versioned_docs/version-3.8/backup-restore.mdx index c38f48d0..0c722ac5 100644 --- a/versioned_docs/version-3.8/backup-restore.mdx +++ b/versioned_docs/version-3.8/backup-restore.mdx @@ -30,7 +30,7 @@ We also provide a simple client program called [scalar-admin](https://github.com Note that when you use a point-in-time-restore/recovery mechanism, it is recommended to minimize the clock drifts between nodes (ScalarDL nodes and a client node that requests a pause) by using clock synchronization such as NTP. Otherwise, the time you get as a paused duration might be too different from the time in which the pause was actually conducted, which could restore to a point where ongoing transactions exist. -Also, it is recommended to pause a long enough time (e.g., 10 seconds) and use the mid-time of the paused duration since clock synchronization cannot perfectly synchronize clocks between nodes. +Also, it is recommended to pause a long enough time (for example, 5 seconds) and use the mid-time of the paused duration since clock synchronization cannot perfectly synchronize clocks between nodes. #### Database-specific ways to create a transactionally-consistent backup @@ -43,10 +43,6 @@ However, if the quorum of nodes of a cluster loses their data, we need a transac If you want to create a transactionally-consistent cluster-wide backup, please follow [the basic strategy](#basic-strategy-to-create-a-transactionally-consistent-backup) section, or stop the Cassandra cluster and take the copies of all the nodes of the cluster, and start the cluster. -To avoid mistakes, it is recommended to use [Cassy](https://github.com/scalar-labs/cassy). -Cassy is also integrated with [`scalar-admin`](https://github.com/scalar-labs/scalar-admin) so it can issue a pause request to the application of a Cassandra cluster. -Please see [the doc](https://github.com/scalar-labs/cassy/blob/master/docs/getting-started.md#take-cluster-wide-consistent-backups) for more details. - **Cosmos DB** You must create a Cosmos DB account with a Continuous backup policy enabled to use point-in-time restore (PITR) feature. Backups are created continuously after it is enabled. diff --git a/versioned_docs/version-3.8/getting-started.mdx b/versioned_docs/version-3.8/getting-started.mdx index dc07bd90..d5f9e59e 100644 --- a/versioned_docs/version-3.8/getting-started.mdx +++ b/versioned_docs/version-3.8/getting-started.mdx @@ -119,7 +119,7 @@ Note that you can only add new certs and cannot update existing certs in place f ## Create a contract -Contracts in ScalarDL are simply Java classes that extend the predefined base contract classes (such as [JacksonBasedContract](https://scalar-labs.github.io/scalardl/javadoc/latest/ledger/com/scalar/dl/ledger/contract/JacksonBasedContract.html) class) and override the `invoke` method. Let's take a closer look at the [StateUpdater.java](https://github.com/scalar-labs/scalardl-java-client-sdk/blob/master/src/main/java/com/org1/contract/StateUpdater.java) contract which creates an asset and associates some states with it. +Contracts in ScalarDL are simply Java classes that extend the predefined base contract classes (such as [`JacksonBasedContract`](https://scalar-labs.github.io/scalardl/javadoc/latest/ledger/com/scalar/dl/ledger/contract/JacksonBasedContract.html) class) and override the `invoke` method. Let's take a closer look at the [StateUpdater.java](https://github.com/scalar-labs/scalardl-java-client-sdk/blob/master/src/main/java/com/org1/contract/StateUpdater.java) contract which creates an asset and associates some states with it. ```java package com.org1.contract; @@ -237,7 +237,7 @@ First, you should always use `ClientServiceFactory` to create `ClientService` ob `ClientServiceFactory` caches objects required to create `ClientService` and reuses them as much as possible on the basis of given configurations, so `ClientServiceFactory` object should always be reused. `ClientService` is a thread-safe client that interacts with ScalarDL components (e.g., Ledger and Auditor) to register certificates, register contracts, execute contracts, and validate data. -When you execute a contract, you need to specify the corresponding argument type of the contract. For example, if your contract extends JacksonBasedContract, you need to pass JsonNode argument when you execute the contract. +When you execute a contract, you need to specify the corresponding argument type of the contract. For example, if your contract extends `JacksonBasedContract`, you need to pass JsonNode argument when you execute the contract. For more information, please take a look at [Javadoc](https://scalar-labs.github.io/scalardl/javadoc/). diff --git a/versioned_docs/version-3.8/how-to-use-proof.mdx b/versioned_docs/version-3.8/how-to-use-proof.mdx index e2b8595b..0e5634e4 100644 --- a/versioned_docs/version-3.8/how-to-use-proof.mdx +++ b/versioned_docs/version-3.8/how-to-use-proof.mdx @@ -22,9 +22,9 @@ Thus, making use of Asset Proofs appropriately could reduce the risk of tamperin You can get Asset Proofs ([AssetProof](https://scalar-labs.github.io/scalardl/javadoc/latest/common/com/scalar/dl/ledger/asset/AssetProof.html)) from the result ([ContractExecutionResult](https://scalar-labs.github.io/scalardl/javadoc/latest/common/com/scalar/dl/ledger/model/ContractExecutionResult.html)) of the `executeContract` method of the SDKs. A proof can be validated if it is not tampered and it is from the Ledger by verifying the signature. -It is recommended to store the proofs outside of a domain in which the Ledger runs so that malicious activities in one domain can be detected by the other domain. It is worth considering storing proofs in cloud storages for ease of management. +It is recommended to store the asset proofs outside of a domain in which the Ledger runs so that malicious activities in one domain can be detected by the other domain. It is worth considering storing asset proofs in cloud storages for ease of management. -The proofs obtained in execution can be utilized when you do `validateLedger`. `validateLedger` also returns the proof of a specified asset record after doing Ledger-side validation. Then, the client can check if the proof is the same as the one that have returned from the Ledger before. +The asset proofs obtained in execution can be utilized when you do `validateLedger`. `validateLedger` also returns the proof of a specified asset record after doing Ledger-side validation. Then, the client can check if the asset proof is the same as the one that have returned from the Ledger before. ## ScalarDL Auditor diff --git a/versioned_docs/version-3.8/how-to-write-contract.mdx b/versioned_docs/version-3.8/how-to-write-contract.mdx index 38aa7823..0cd1010e 100644 --- a/versioned_docs/version-3.8/how-to-write-contract.mdx +++ b/versioned_docs/version-3.8/how-to-write-contract.mdx @@ -76,7 +76,7 @@ The `StateUpdater` contract first checks if the argument has proper variables, m Then the contract retrieves an `asset_id` and `state` given from the requester and retrieves `asset` from the Ledger with the specified `asset_id`. And it updates the asset's state if the asset doesn't exist or the asset's state is different from the current state. A contract might face some `RuntimeException` when interacting with the Ledger, but it shouldn't catch it in the contract. All the exceptions are treated properly by the ScalarDL executor. -This contract will just create or update the state of an specified asset, so it doesn't need to return anything to the requester. So in this case, it can return `null`. If you want to return something to a requester, you can return an arbitrary `JsonNode` when using JacksonBasedContract. +This contract will just create or update the state of an specified asset, so it doesn't need to return anything to the requester. So in this case, it can return `null`. If you want to return something to a requester, you can return an arbitrary `JsonNode` when using `JacksonBasedContract`. ### Grouping assets The value of `asset_id` can be arbitrarily defined but it is a good practice to have some rules when you want to group assets. diff --git a/versioned_docs/version-3.8/schema-loader.mdx b/versioned_docs/version-3.8/schema-loader.mdx index 33a14daa..0c5b7430 100644 --- a/versioned_docs/version-3.8/schema-loader.mdx +++ b/versioned_docs/version-3.8/schema-loader.mdx @@ -1,6 +1,6 @@ # ScalarDL Schema Loader -A Docker image that loads the database schemas of ScalarDL using [Schema Tool for Scalar DB](https://scalardb.scalar-labs.com/docs/latest/schema-loader). +A Docker image that loads the database schemas of ScalarDL using [Schema Tool for ScalarDB](https://scalardb.scalar-labs.com/docs/latest/schema-loader). ## How to Run