It is nice to see all the keys that exists in a single enum
Also, rename CWalletKey to OldKey and update the outdated documentation
It is nice to see all the keys that exists in a single enum
Also, rename CWalletKey to OldKey and update the outdated documentation
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Concept ACK. This seems like an improvement to code self-documentation.
I think this would be even more helpful if the DBKeys namespace had documentation for each of the keys and what they're used for.
We could go further and change this to an enum, which would ensure that only known keys are read/written, and would allow us to tidy the long sequence of if-else statments in ReadKeyValue() into a switch statement.
692 | - explicit CWalletKey(int64_t nExpires=0); 693 | - 694 | ADD_SERIALIZE_METHODS; 695 | 696 | template <typename Stream, typename Operation> 697 | inline void SerializationOp(Stream& s, Operation ser_action) {
fa6f22bf44c0f741285f27f27ac18e9679802e5e
Could go further and just implement Unserialize?
I kept the changes to a minimum. Happy to add a commit for this, if other think it is useful.
utACK fa6f22bf44c0f741285f27f27ac18e9679802e5e
Agree with John though, the PR title says enumerate so why not use an enum?
why not use an enum
The underlying type on an enum in cpp can only be integer, not std::string.
I could switch it to an enum and then add helper methods for std::string -> enum and enum -> std::string, but I don't see the benefit.
We could go further and change this to an enum, which would ensure that only known keys are read/written
I don't understand how this would prevent anyone from inlining a string literal (bypassing the enum).
and would allow us to tidy the long sequence of if-else statments in ReadKeyValue() into a switch statement.
You'd still have to do the if-else statements elsewhere, so I don't see the benefit. I know a log(N) map lookup would also work, but I think the computational complexity shouldn't be a concern here.
ACK fa6f22bf44c0f741285f27f27ac18e9679802e5e, I'm a big fan of this kind of change as it prevents typos, which can happen with 'magic' strings in the code.
I don't understand how this would prevent anyone from inlining a string literal (bypassing the enum).
The idea would be to change WriteIC and EraseIC to take the enum rather than a string.
Changing this to an enum was a suggested follow-up. This PR is a useful change by itself.
416 | strErr = "Error reading wallet database: Unknown non-tolerable wallet flags found"; 417 | return false; 418 | } 419 | - } else if (strType != "bestblock" && strType != "bestblock_nomerkle" && 420 | - strType != "minversion" && strType != "acentry" && strType != "version") { 421 | + } else if (strType != DBKeys::BESTBLOCK && strType != DBKeys::BESTBLOCK_NOMERKLE &&
(maybe for a followup) I think it would be better to define a const set of the types that are unused but kept around to avoid triggering unknown record warnings. Then we could change this if to be checking membership in that set.
425 | @@ -431,8 +426,8 @@ ReadKeyValue(CWallet* pwallet, CDataStream& ssKey, CDataStream& ssValue, 426 | 427 | bool WalletBatch::IsKeyType(const std::string& strType) 428 | { 429 | - return (strType== "key" || strType == "wkey" || 430 | - strType == "mkey" || strType == "ckey"); 431 | + return (strType == DBKeys::KEY || strType == DBKeys::OLD_KEY ||
(maybe for a followup) I think it would be better to define a const set of the types that are keys. Then we could change this function to be returning membership in that set.
Code review ACK fa6f22bf44c0f741285f27f27ac18e9679802e5e
Thanks for the plethora of suggestions of follow-up refactorings. To not invalidate the ACKs and to not scope creep this change, which should be minimal, but still an improvement, I will leave them for later.
ACK fa6f22bf44c0f741285f27f27ac18e9679802e5e - I had a quick look over, definitely prefer this to strings floating around everywhere.
5 ACKs, including both the wallet maintainers, means I'll merge this now and all the follow ups can be done in a new PR. I like the idea of using a const set of types.
post-merge ACK fa6f22bf44c0f741285f27f27ac18e9679802e5e
Potential follow-up PRs:
DBKeys where they're defined (https://github.com/bitcoin/bitcoin/pull/16475#issuecomment-515787564)OldKey serialization logic and just keep deserialization (https://github.com/bitcoin/bitcoin/pull/16475#discussion_r308018873)