-
Notifications
You must be signed in to change notification settings - Fork 269
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: implement the lazy_set
feature
#750
Conversation
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.
overall changes look good to me, would like a few more approvals before merging
cmd/dbgenerator/README.md
Outdated
## Usage | ||
|
||
It takes 4 arguments: | ||
- dbtype: the type of database to use. |
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.
Can dbtype
be inferred from the database?
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.
maybe, the purpose of this tool is to generate the legacy tree, it can be used in benchmarking and dbtype
is useful to compare different db performance
@cool-develope seems some tests are still failing |
it seems like the dbdir removing is not working properly in GA |
@@ -21,7 +21,7 @@ type KVPairReceiver func(pair *KVPair) error | |||
// | |||
// The algorithm don't run in constant memory strictly, but it tried the best the only | |||
// keep minimal intermediate states in memory. | |||
func (ndb *nodeDB) extractStateChanges(prevVersion int64, prevRoot *NodeKey, root *NodeKey, receiver KVPairReceiver) error { | |||
func (ndb *nodeDB) extractStateChanges(prevVersion int64, prevRoot, root []byte, receiver KVPairReceiver) error { |
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.
I'm a big fan of this change in particular. Actually it's what I originally recommended. #676 (review)
leftNodeKey *NodeKey | ||
rightNodeKey *NodeKey | ||
leftNodeKey []byte | ||
rightNodeKey []byte |
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.
🤩
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.
I propose taking this further. Why not define nodeKey []byte
and store version and nonce as private, top-level fields on Node
?
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.
[]byte nodeKey
is meaningless, leftNodeKey
and rightNodeKey
is used in getting children
The only thing we need is nonce
and version
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.
NodeKey
seems also without meaning, just makes the code harder to read. if we need nonce
and version
why not put it on Node
directly?
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.
good question, the nonce and version are used together in several encodings, so I created the specific struct NodeKey
and also it ensures version+nonce
as a node key
we should probably use |
migrate_test.go
Outdated
} | ||
} | ||
|
||
cmd := exec.Command("sh", "-c", fmt.Sprintf("cd cmd/dbgenerator && go run . %s %s random %d %d", dbType, dbDir, version, version/2)) //nolint:gosec |
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.
Can we import it as library, since it's all golang code here
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.
it will cause circular dependency since we are in v1, go.mod
doesn't analyze the iavl
imports
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.
LGTM, the only concern is the uint32 nonce overflow in genesis, but there's still a long way to go before production data reach that limit, and we can probably find some workarounds for genesis version in the future.
@tac0turtle , it seems like 5mins is not enough for test since I added |
Closes: #747