Instead of returning a Dbc (BDB cursor object) and having the caller deal with the cursor, make BerkeleyBatch handle the cursor internally.
Split from #18971
<!--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.
869 | + bool ret = m_batch.ReadAtCursor(ssKey, ssValue, complete); 870 | + if (complete) { 871 | + m_batch.CloseCursor(); 872 | break; 873 | - else if (ret != 0) 874 | + }
Nit: coding style } else if (!ret) {
Fixed.
This does limit flexibility a bit, though I guess one cursor at a time is enough for all our current and future use cases.
738 | @@ -738,27 +739,32 @@ void BerkeleyDatabase::ReloadDbEnv() 739 | } 740 | } 741 | 742 | -Dbc* BerkeleyBatch::GetCursor() 743 | +bool BerkeleyBatch::CreateCursor()
I think StartCursor would be a better name, after all, the whole process (including details like whether something is created) is internal.
Renamed to StartCursor.
This does limit flexibility a bit, though I guess one cursor at a time is enough for all our current and future use cases.
If another cursor was needed, you could use another Batch object. But we barely use cursors, so one is enough for now.
If another cursor was needed, you could use another Batch object. But we barely use cursors, so one is enough for now.
Ohh! I missed that it's on the batch, not on the database object.
744 | @@ -742,8 +745,8 @@ DBErrors WalletBatch::LoadWallet(CWallet* pwallet) 745 | if (!strErr.empty()) 746 | pwallet->WalletLogPrintf("%s\n", strErr); 747 | } 748 | - pcursor->close();
In commit "walletdb: Handle cursor internally" (cda86544ae9de430e4558b87945046d5612202ac)
Minor: I think it'd be a little clearer to keep this close here as m_batch.CloseCursor() so it's more obvious cursor is closed in all cases, and so you don't need to add a new close call in a different place above.
But above, in https://github.com/bitcoin/bitcoin/pull/19308/files#diff-e506682270036e4c8e0b8159a34b652dR723, it returns so it needs to be closed there, or am I missing something?
I've moved it to after the catch block and removed the ones inside the loop except for the ones right before the early return.
Code review ACK cda86544ae9de430e4558b87945046d5612202ac. Nice to make cursor usage safer & more generic, even if it's a slightly less flexible than before (limited to single cursor per batch). I left minor style suggestion below, but feel free to ignore
751 | + int ret = pdb->cursor(nullptr, &m_cursor, 0); 752 | if (ret != 0) 753 | - return nullptr; 754 | - return pcursor; 755 | + return false; 756 | + return true;
nit, just return ret == 0.
Done
Concept ACK.
Instead of returning a Dbc (BDB cursor object) and having the caller
deal with the cursor, make BerkeleyBatch handle the cursor internally.
This prepares BerkeleyBatch to work with other database systems as Dbc
objects are BDB specific.
757 | 758 | -int BerkeleyBatch::ReadAtCursor(Dbc* pcursor, CDataStream& ssKey, CDataStream& ssValue) 759 | +bool BerkeleyBatch::ReadAtCursor(CDataStream& ssKey, CDataStream& ssValue, bool& complete) 760 | { 761 | + complete = false; 762 | + if (m_cursor == nullptr) return false;
assert(m_cursor)? There was no check for pcursor.
I don't think an assert is necessary.
If it's something that can't happen then an assertion is fine. Also, it means that StartCursor must be called before.
If I have to push again.
334 | @@ -335,7 +335,7 @@ void BerkeleyEnvironment::CheckpointLSN(const std::string& strFile) 335 | } 336 | 337 | 338 | -BerkeleyBatch::BerkeleyBatch(BerkeleyDatabase& database, const char* pszMode, bool fFlushOnCloseIn) : pdb(nullptr), activeTxn(nullptr) 339 | +BerkeleyBatch::BerkeleyBatch(BerkeleyDatabase& database, const char* pszMode, bool fFlushOnCloseIn) : pdb(nullptr), activeTxn(nullptr), m_cursor(nullptr)
nit, move these to header.
I'm pretty sure that won't compile.
I mean 04998ef3cb866b2371bb047a5091787f61692588.
Ah. Maybe if I have to push again.
Code review ACK ca24edfbc1941ed0a3c9586416dae4e84794eb66. Changes since last review: StartCursor rename, moving CloseCursor calls near returns
Code review ACK ca24edfbc1941ed0a3c9586416dae4e84794eb66.