Skip to content
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

Move badger, tests and benchmarks to sub-modules #28

Closed
wants to merge 9 commits into from

Conversation

muXxer
Copy link

@muXxer muXxer commented Nov 20, 2023

Hello! 👋

I don't know if that is the best way to do it, and if you like the change at all, but this PR is trying to get rid of the badger dependency for users that don't need the badger KVStore, by moving the badger implementation to a new module called "github.com/pokt-network/smt/kvstore".

This dependency was introduced in #19

@reviewpad reviewpad bot added large Pull request is large waiting-for-review This PR is currently waiting to be reviewed labels Nov 20, 2023
Copy link
Collaborator

@h5law h5law left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @muXxer 👋🏻 Love to see your interest in the SMT!

Before I do a full review I have a few higher level requests. I like the idea of removing the badgerDB dependency by introducing a submodule. However I think moving the benchmarks and tests into submodules isn't the right move.

This approach forces a lot of methods to be exposed that we don't need to be exposed.

I think re-introducing the SimpleMap and having the MapStore conform to the same interface we use with badger would be ideal. The methods on the interface related to backups and restoration would be no-op but this would allow users to use either a simple go map type or the badger db for a more production use case.

So what do you think of moving the benchmarks and tests back into the main package, unexporting the methods that were changed and replacing the tests usage of badger with the MapStore (this can be copy pasted from older versions probably with little changes)? This way we can still keep unexposed numerous methods that don't need to be exposed publicly, and also remove the dependency on badger for those that dont want it, while still keeping a builtin kvstore.

@Olshansk
Copy link
Member

Firstly, love the idea of removing the explicit dependency on badger as I think it'd be nice to experiment & explore with stores likes boltdb or rocksdb as well.

+1 to @h5law's suggestion, so let us know what you think.

@muXxer Also, we have other plans/ideas for features we want to add (e.g. making the smt support k-ary children instead of just binary children) in the future. Feel free to give us a heads up to make sure that we don't accidentally duplicate your work.

@muXxer
Copy link
Author

muXxer commented Nov 23, 2023

Hi @h5law and @Olshansk,
sorry for the late response, I didn't see the github notification.

@h5law to you suggestion, I actually thought exactly the same when I did these changes. Exporting all the functions just because of the tests and benchmarks is quite ugly, and a map implementation would be nicer indeed. But I was in a rush when I did that, and I thought it's good to get some feedback first. 😅

I can try to do it the way you said 👍

Actually, we already have another KVStore interface in our codebase, which you maybe could use instead if you want. 😅
We have support for a map based KVStore there as well, and RocksDB. In the past we also had badger/v3 and bbolt, but we removed those because RocksDB is by fast the fastest and most reliable so far. https://github.com/iotaledger/hive.go/tree/develop/kvstore

@muXxer muXxer force-pushed the chore/remove-dependencies branch 8 times, most recently from f372fc5 to 84d8fcc Compare November 23, 2023 17:00
@muXxer muXxer force-pushed the chore/remove-dependencies branch from 84d8fcc to 35cb503 Compare November 23, 2023 17:02
@muXxer
Copy link
Author

muXxer commented Nov 23, 2023

@h5law done!

I reverted all exposures of the internal smt methods.

Some things to consider:

  • the SimpleMap has some weird behaviours because I adapted it to the checks done in kvstore_test.go, but those come from weird badger behaviour in the first place... (like checking for key size during deletion etc)
  • you need to remove the replace directive and the magic hash in the badger/go.mod, I can't do this because I can't push to the original upstream repo, so I can't reference an older commit of myself (maybe directly after the PR gets merged?)
  • I deactivated the restore/backup test for SimpleMap 🤷
  • I'm not sure if the badger tests get executed by your CI 🏃

@muXxer muXxer requested a review from h5law November 23, 2023 17:14

type badgerKVStore struct {
db *badger.DB
last_backup uint64 // timestamp of the most recent backup
}

var badgerToSMTErrorsMap = map[error]error{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add some quick comments explaining this map and the conversion function in the godoc format


go 1.20

replace github.com/pokt-network/smt => ../../
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
replace github.com/pokt-network/smt => ../../

Saw your comment, if we remove this, now I have enabled CI for this PR lets see what happens. I can always prepare a follow up PR that is based off this that we ultimately merge in instead

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to remove the line and update to the correct commit in your follow up PR, which should be merged directly after this one.

"encoding/hex"
"fmt"
"io"
"slices"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requires go 1.21 - might as well update the repo, you'll have to adjust the workflow files in the .github directory and update the note in the readme. CI should catch this stuff now

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to 1.21 👍

Key []byte
}

func (e *InvalidKeyError) Error() string {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add some godoc comments similar to the badger KVStore ones (copy paste will probably be enough with minor changes) to all the functions and structs in here.

"testing"
)

func TestSimpleMap(t *testing.T) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this file? Is this not covered in simplemap/kvstore_test.go?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept it because it was part of the former removed SimpleMap, I only adapted it to this version.
But I guess you are right, the kvstore_test should already cover that. I removed the file again.

Copy link
Collaborator

@h5law h5law left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@muXxer Overall love the PR! Thanks for addresses the comments before I did a review.

Left some comments, mostly around godoc comments - I think its better to have them even on non-exported functions just for readability.

Otherwise love the direction this is going in. As @Olshansk one of my goals with this repo is to expand the maps. I will have a look into your KVStore interface and see what I can do!

To give some context I want to make this a k-ary tree eventually where the user can decide which k they desire. Having multiple maps as submodules like how you have done with our badger map is going to be a huge benefit. I will work on adding support for more and more over time.

CI should run on these commits now so lets see if removing your "go mod magic" works as is. However if not, I will open a PR after the comments have been addressed here and we can merge that one in, but lets give it a go first.

If you have any other requests or PRs please open issues/PRs and we can work on them! Want to see this tree get some more adoption in the industry!

@Olshansk
Copy link
Member

@h5law Thanks for diving into the review. I'll take a look after the first round is addressed.

@muXxer Excited to give RocksDB a shot :)

@Olshansk
Copy link
Member

@muXxer Wanted to bump and see if you're still interesting in pushing forward with this PR?

@h5law
Copy link
Collaborator

h5law commented Dec 15, 2023

@muXxer I have been putting some thought into this and can tackle it after Christmas if there isn't a rush on your end.

@muXxer
Copy link
Author

muXxer commented Dec 22, 2023

@h5law @Olshansk sorry that this took so long, I was pretty busy and then I almost forgot about this 😅
Hope the changes are ok now.

@h5law
Copy link
Collaborator

h5law commented Dec 22, 2023

@muXxer it seems you may not be able to tackle this one so check out #33 and see if this suits your needs better

@Olshansk
Copy link
Member

Olshansk commented Jan 3, 2024

Closing this out now that #33 and #34 were merged in.

@Olshansk Olshansk closed this Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
large Pull request is large waiting-for-review This PR is currently waiting to be reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants