Closed faddat closed 7 months ago
Attention: Patch coverage is 50.00000%
with 2 lines
in your changes are missing coverage. Please review.
Project coverage is 77.26%. Comparing base (
fb4f703
) to head (e3118b3
). Report is 11 commits behind head on main.
@melekes -- this is my new proposed PR. It is simpler, easier to maintain, and faster all around.
It will also reduce dramatically the amount of work needed to maintain both this repository and cometbft.
The correct answer to your question about the Dockerfile, is that there's been no reason to have a Dockerfile in this repository for years.
When this PR started, tests took more than ten minutes. They now take less than one minute.
Why keep goleveldb if it's unmaintained?
@melekes -- backwards compatibility for in production chains.
Unfortunately I think we will want to support it for some time to come.
The best solution would be to make sure that no new chains are started using goleveldb, and include in the notes on db config that teams should migrate from goleveldb to pebble.
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@melekes - this is now being marked as stale, do you reckon we want to use it?
I agree with the general direction 👍 and would like to see this merged.
Cool, please let me know what else can be polished up to get this in.
I think I just fixed that annoying codeql thing.
eliminates unmaintained database backends with no future: bolt badger
badger is very much maintained https://github.com/dgraph-io/badger
@melekes it is pure go, too, so would you like to keep it?
I think this is ready to rock now, but there is a valid question of weather or not to include badger.
Badger v4 worked out of the box. No valid reason not to include it.
If we are going to merge this, we should. Blocks upgrading comet to go 1.22
I would prefer to sunset database backends iteratively:
I would also keep rocksdb around, since some users (at least Cronos, potentially others) clearly make use of it.
Therefore, we should separate this PR into multiple smaller PRs:
@faddat do you plan on helping with any of the above? if so, please open corresponding PRs. if not, we plan to work on it this week so we'll go ahead within a couple of days
@adizere
it is necessary to update the dockerfile in order to update grocksdb. So ci will take a very long time now.
As for phases, that's fine.
We will not be able to improve docker without removing rocksdb (and other databases that use cgo)
This PR: