Update Database on project

[stdevMac]

• Add transaction database (oriented to transactions)
• Minor changes on names and comments

[codecov]

Codecov Report

Merging #158 (9c72866) into main (a9841aa) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main      #158   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           34        36    +2     
  Lines         3690      3762   +72     
=========================================
+ Hits          3690      3762   +72     

Flag	Coverage Δ
unittests	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
internal/db/abi/abi.go	100.00% <ø> (ø)
internal/db/abi/manager.go	100.00% <ø> (ø)
internal/db/block_specific.go	100.00% <ø> (ø)
internal/db/sorted_list.go	100.00% <ø> (ø)
internal/db/state/code.go	100.00% <ø> (ø)
internal/db/state/storage.go	100.00% <ø> (ø)
internal/db/transaction/manager.go	100.00% <ø> (ø)
internal/db/transaction/transaction.go	100.00% <ø> (ø)
internal/services/transactions.go	100.00% <ø> (ø)
internal/db/db.go	100.00% <100.00%> (ø)
... and 4 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a9841aa...9c72866. Read the comment docs.

[tshakalekholoane]

Looks good but just a couple of issues:

1. The db package is becoming increasingly specialised to Juno's requirements so I think we should have this moved to the internal in the root directory of the repository.
2. Although not documented, the file name convention is all lowercase or lowercase with underscores. I have a preference for the former as _xxx.go prefixes tend to be used as directives on how the toolchain interacts with these files i.e. _test.go, _linux.go, _arm.go, and so on. (See issue).
3. It is not clear to me why is the abi, state, and transaction packages coupled with the database. If they are related to how such objects are handled by the database then they should be under an internal directory under db which is also makes point 1. more pertinent. Shouldn't we also apply similar treatment to blocks as well? So instead of blockSpecific we could have block and treat that similarly to state and transaction?
4. Using separators i.e. 268_435_456 and providing more context on the values that set the geometry might improve readability.
5. Do we need a separate db_test package?

[adriantpaez]

Looks good but just a couple of issues:

1. The db package is becoming increasingly specialised to Juno's requirements so I think we should have this moved to the internal in the root directory of the repository.
2. Although not documented, the file name convention is all lowercase or lowercase with underscores. I have a preference for the former as _xxx.go prefixes tend to be used as directives on how the toolchain interacts with these files i.e. _test.go, _linux.go, _arm.go, and so on. (See issue).
3. It is not clear to me why is the abi, state, and transaction packages coupled with the database. If they are related to how such objects are handled by the database then they should be under an internal directory under db which is also makes point 1. more pertinent. Shouldn't we also apply similar treatment to blocks as well? So instead of blockSpecific we could have block and treat that similarly to state and transaction?
4. Using separators i.e. 268_435_456 and providing more context on the values that set the geometry might improve readability.
5. Do we need a separate db_test package?

About 3. :db package has a simple database implementation without any data type associated, and abi, state and transactions are databases for each of that types

[adriantpaez]

Looks good but just a couple of issues:

1. The db package is becoming increasingly specialised to Juno's requirements so I think we should have this moved to the internal in the root directory of the repository.
2. Although not documented, the file name convention is all lowercase or lowercase with underscores. I have a preference for the former as _xxx.go prefixes tend to be used as directives on how the toolchain interacts with these files i.e. _test.go, _linux.go, _arm.go, and so on. (See issue).
3. It is not clear to me why is the abi, state, and transaction packages coupled with the database. If they are related to how such objects are handled by the database then they should be under an internal directory under db which is also makes point 1. more pertinent. Shouldn't we also apply similar treatment to blocks as well? So instead of blockSpecific we could have block and treat that similarly to state and transaction?
4. Using separators i.e. 268_435_456 and providing more context on the values that set the geometry might improve readability.
5. Do we need a separate db_test package?

Abou 3.: blockSpecific is a kind of database used to store values that can change in a block and we need to get the correct value in a specific block too. An example of that is contract storage, because the storage may change in a transaction. Not confuse it with storing the blocks. To store the blocks we use a simple key-value database without any version control.

[tshakalekholoane]

LGTM.