Make in-memory Merkle tree immutable #2701
Conversation
pav-kv
force-pushed
the
immutable_merkle
branch
2 times, most recently
from
af66de7 to
5c6d926
Compare
pav-kv
force-pushed
the
immutable_merkle
branch
from
5c6d926 to
914ee91
Compare
pav-kv
force-pushed
the
immutable_merkle
branch
from
91737c9 to
59220f5
Compare
|
On a second thought, perhaps it's better to leave this type as is, so that it's simpler. It is used only for testing, so it should be intuitive. The "feature" of this approach allows implementing transactions on Merkle trees. For example, in an in-memory Merkle tree storage. However, I don't think we would need it soon. |
|
Making |
|
Please review #2706 instead. |
| @@ -124,16 +124,16 @@ var testProofs = []proofTestVector{ | |||
| }}, | |||
| } | |||
|
|
|||
| func decodeHexStringOrPanic(hs string) []byte { | |||
| // hx decodes a hex string or panics. | |||
| func hx(hs string) []byte { | |||
There was a problem hiding this comment.
This change is unrelated to this CL, right?
Although I like the shortness, after this PR, it is unclear from looking at the name of this function wether is decodes or encodes a string in hex
There was a problem hiding this comment.
Yeah, this could be separated, I just did it as a drive-by because otherwise the lists of constants would look too verbose.
This file was old and ugly anyway, so #2707 refactors it. After the refactoring, hx is used only with constants that are inlined, e.g. hx("6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d"), and never used with variables like hx(someVariable). So it's obvious from context that it decodes, and the pros is that the name is short.
This change makes the
inmemory.TreeMerkle tree type behave similarly to a regular Go slice.It provides variadic
Append*methods which most of the time reuse memory, but may reallocateand copy data. It is safe to reuse all previous
Treeobjects for reads, and it is possible to rollback and use for writes (with caution, knowing that it may rewrite hashes of any bigger
Tree).