hiero-ledger / hiero-ledger/hiero-consensus-node

Let `ReadableKVState` and `WriteableKVState` require Records as values

Open
#4,614 3 comments 0 reactions 1 assignee Claimed by @manishdait View on GitHub
Good First Issue Candidate hacktoberfest Platform
Dominant language
Java
Stars
406
Forks
226
Avg merge
3d 4h
Merged PRs (30d)
210

Description

## 🆕🐥 First Timers Only

This issue is reserved for people who have never contributed to [Hedera](https://hedera.com) or any open source project in general.
We know that creating a pull request (PR) is a major barrier for new contributors.
The goal of this issue and all other issues labeled by [**'good first issue'**](https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3Ahashgraph+archived%3Afalse+label%3A%22good+first+issue%22+) is to help you make your first contribution to Hedera.

## 👾 Description of the issue

The are two primary interfaces for interacting with key/value data in the state (akin to a database): `ReadableKVState.java` and `WriteableKVState.java`. The former is used for reading data in a key/value state, and the latter is for updating data in a key/value state. The values read from and provided to these interfaces should always be records which are inherently immutable. When providing a new value to the `WriteableKVState`, another instance of the record is made with the updated values. This new record is provided to the `WriteableKVState`. The problem is that the interfaces do not strictly enforce this. It is possible to create implementations of `ReadableKVState` and `WriteableKVState` that do not use immutable data, which could lead to bugs.

### Steps to reproduce

See the `ReadableKVState.java` and `WriteableKVState.java` interfaces. Observe that the use of `records` for the parameterized value `V` is not required to be a `record`.

### Proposed Solution:

Update the definitions of `ReadableKVState` and `WriteableKVState` to:

`public interface ReadableKVState`
`public interface WritableKVState extends ReadableKVState`

Once these changes are made, other class definitions will need the same change so they are compatible. These can be found by attempting to compile the project. In addition, there are unit tests that use `String` as values. While java strings are immutable, they do not extend `Record` so they must be updated to be compatible. This can be accomplished by creating a record wrapper:

`public record StringRecord(String value) {}`

and updating values used from

`String APPLE = "Apple"`

to

`StringRecord APPLE = new StringRecord("Apple")`

## 📋 Step by step guide to do a contribution

If you have never contributed to an open source project at GitHub, the following step-by-step guide will introduce you to the workflow. More information and concrete samples for shell commands for each step can be found in our [CONTRIBUTING.md](https://github.com/hashgraph/.github/blob/main/CONTRIBUTING.md) file.
A more detailed general documentation of the GitHub PR workflow can be found [here](https://github.com/firstcontributions/first-contributions/blob/master/README.md).

- [ ] **Claim this issue:** Comment below that you are interested in working on the issue
- [ ] **Wait for assignment:** A community member with the given rights will add you as an assignee of the issue
- [ ] **Fork the repository:** You can do that in GitHub (by simply clicking the 'fork' button).
- [ ] **Check out the forked repository**
- [ ] **Create a feature branch** for the issue. We do not have a hard naming definition for branches but it is best practice to prefix the branch name with the issue id.
- [ ] **Solve the issue** in your branch.
- [ ] **Commit your changes:** Here, it is needed to add `sign-off` information to the commit to accept the "Developer Certificate of Origin" (https://developercertificate.org). More details can be found in our [CONTRIBUTING.md](https://github.com/hashgraph/.github/blob/main/CONTRIBUTING.md)
- [ ] **Start a Pull Request (PR)**: We have a pattern for naming pull requests that a GitHub Action checks. We use that pattern to support the creation of automatic release notes.
- [ ] **Check GitHub Actions:** Several GitHub Actions will be triggered automatically for each PR. If a GitHub Action fails and you do not understand the cause of that error do not hesitate to add a comment to the PR and ask the Hedera developer community for support.
- [ ] **Wait for reviews:** Members of the Hedera developer community will review your PR. If a reviewer finds any missing pieces or a problem, he or she will start a discussion with you and describe the next steps for solving the problem.
- [ ] **You did it 🎉:** We will merge the fix in the develop branch. Thanks for being part of the Hedera community as an open-source contributor ❤️

## 🎉 Contribute to Hacktoberfest

Solve this issue as part of the [Hacktoberfest](https://hacktoberfest.digitalocean.com) event and get a chance to receive cool goodies like a T-Shirt. 🎽

## 🤔 Additional Information

If you have any questions, just ask us directly in this issue by adding a comment. You can join our community chat at [Discord](https://hedera.com/discord). A general manual about open-source contributions can be found [here](https://github.com/firstcontributions/first-contributions/blob/master/README.md).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.