-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(pkg/db): remove cleveldb, fsdb and rocksdb #1714
Conversation
This reverts commit e328b31.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1714 +/- ##
==========================================
+ Coverage 47.00% 47.20% +0.19%
==========================================
Files 578 575 -3
Lines 77582 77092 -490
==========================================
- Hits 36471 36393 -78
+ Misses 38076 37666 -410
+ Partials 3035 3033 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the review meeting: let's keep one additional implementation aside from the ones that are currently used. For what @ajnavarro was referring to, we can support functionality of specific databases by adding extra methods, and then using type assertions in usage to verify if they support that (this would likely have to be done anyway, even if we keep as it is now only goleveldb and memdb.) I will update the PR and add support boltdb |
This PR is now updated, and ready for a last review before merging. |
Split from gnolang#1602. Context: > @zivkovicmilos:[^1] Unpopular opinion: we should probably just drop these DBs entirely from the codebase, they are never gonna be used in place of LevelDB in the near future > > @ajnavarro: IMHO the needed database is defined by the application needs, not from any other external usecases. Sticking to one of the existing key/value databases, we can use their special capabilities to make it more performant for our use case (yes, even if they are all key/value DBs, they differ in a lot of low-level functionality). \ > I would say to use one and add support in the future for more if needed. After a discussion in the review meeting w/ @jaekwon, this PR is now changed to maintain another reference implementation with boltdb. It also makes sure that it is selectable, when available, from the tm2 node configuration. After this PR, there are no databases in the codebase using cgo. [^1]: gnolang#1602 (comment)
Split from #1602. Context:
After a discussion in the review meeting w/ @jaekwon, this PR is now changed to maintain another reference implementation with boltdb. It also makes sure that it is selectable, when available, from the tm2 node configuration.
After this PR, there are no databases in the codebase using cgo.
Footnotes
https://github.com/gnolang/gno/pull/1602#discussion_r1490862277 ↩