Martchus
/
lmdb-safe
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
lmdb-safe/tests/basic.cc

336 lines
8.4 KiB
C++
Raw Normal View History

Add CMake build system replacing Makefile * Allow building a shared library with proper exports * Remove bundled catch2 library in favor of searching for system-provided version * Adapt/fix tests and examples to latest changes * Fix several warnings
2022-01-30 00:05:02 +01:00
#include "../lmdb-safe.hh"
add tests, prefix_range
2018-12-28 16:33:20 +01:00
#define CATCH_CONFIG_MAIN
Add CMake build system replacing Makefile * Allow building a shared library with proper exports * Remove bundled catch2 library in favor of searching for system-provided version * Adapt/fix tests and examples to latest changes * Fix several warnings
2022-01-30 00:05:02 +01:00
#include <catch2/catch.hpp>
#include <c++utilities/application/global.h>
add tests, prefix_range
2018-12-28 16:33:20 +01:00
#include <iostream>
using namespace std;
Move everything under a namespace
2022-01-18 22:08:36 +01:00
using namespace LMDBSafe;
add tests, prefix_range
2018-12-28 16:33:20 +01:00
TEST_CASE("Most basic tests", "[mostbasic]") {
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
REQUIRE(1);
MDBDbi main = env.openDB("", MDB_CREATE);
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
add tests, prefix_range
2018-12-28 16:33:20 +01:00
auto txn = env.getRWTransaction();
MDBOutVal out;
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
REQUIRE(txn->get(main, "lmdb", out) == MDB_NOTFOUND);
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
txn->put(main, "lmdb", "hot");
add tests, prefix_range
2018-12-28 16:33:20 +01:00
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
REQUIRE(txn->get(main, "lmdb", out) == 0);
add tests, prefix_range
2018-12-28 16:33:20 +01:00
REQUIRE(out.get<std::string>() == "hot");
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
txn->abort();
add tests, prefix_range
2018-12-28 16:33:20 +01:00
auto rotxn = env.getROTransaction();
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
REQUIRE(rotxn->get(main, "lmdb", out) == MDB_NOTFOUND);
add tests, prefix_range
2018-12-28 16:33:20 +01:00
}
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
TEST_CASE("Range tests", "[range]") {
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
REQUIRE(1);
MDBDbi main = env.openDB("", MDB_CREATE);
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
auto txn = env.getRWTransaction();
MDBOutVal out;
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
REQUIRE(txn->get(main, "lmdb", out) == MDB_NOTFOUND);
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
txn->put(main, "bert", "hubert");
txn->put(main, "bertt", "1975");
txn->put(main, "berthubert", "lmdb");
txn->put(main, "bert1", "one");
txn->put(main, "beru", "not");
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
{
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
auto cursor = txn->getCursor(main);
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
MDBInVal bert("bert");
MDBOutVal key, val;
REQUIRE(cursor.lower_bound(bert, key, val) == 0);
REQUIRE(key.get<string>() == "bert");
REQUIRE(val.get<string>() == "hubert");
REQUIRE(cursor.next(key, val) == 0);
REQUIRE(key.get<string>() == "bert1");
REQUIRE(val.get<string>() == "one");
REQUIRE(cursor.next(key, val) == 0);
REQUIRE(key.get<string>() == "berthubert");
REQUIRE(val.get<string>() == "lmdb");
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
REQUIRE(cursor.lower_bound("kees", key, val) == MDB_NOTFOUND);
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
txn->commit();
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
}
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
auto rotxn = env.getROTransaction();
{
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
auto cursor = rotxn->getCursor(main);
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
MDBInVal bert("bert");
MDBOutVal key, val;
REQUIRE(cursor.lower_bound(bert, key, val) == 0);
REQUIRE(key.get<string>() == "bert");
REQUIRE(val.get<string>() == "hubert");
REQUIRE(cursor.next(key, val) == 0);
REQUIRE(key.get<string>() == "bert1");
REQUIRE(val.get<string>() == "one");
REQUIRE(cursor.next(key, val) == 0);
REQUIRE(key.get<string>() == "berthubert");
REQUIRE(val.get<string>() == "lmdb");
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
REQUIRE(cursor.lower_bound("kees", key, val) == MDB_NOTFOUND);
}
}
TEST_CASE("moving transactions")
{
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
REQUIRE(1);
MDBDbi main = env.openDB("", MDB_CREATE);
auto txn = env.getRWTransaction();
MDBOutVal out;
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
REQUIRE(txn->get(main, "lmdb", out) == MDB_NOTFOUND);
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
txn->put(main, "bert", "hubert");
txn->put(main, "bertt", "1975");
txn->put(main, "berthubert", "lmdb");
txn->put(main, "bert1", "one");
txn->put(main, "beru", "not");
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
auto cursor = txn->getCursor(main);
Re-work the class hierarchy of cursors and transactions MDBRWTransaction now inherits from MDBROTransaction. Both transaction types will free their cursors before aborting or committing. In addition, transactions are now virtual classes. The reason for this is that RW and RO transactions are handled very differently in LMDB. Nevertheless, it is very useful to be able to write read-only code in a way which also can use an RW transaction. This saves code duplication or unnecessary templates. Since the only methods which are reqiured to be virtual on transactions for this to work are the destructor and the abort/commit methods, the overhead should be neglegible. This also comes in very handy when going forward to implement nested transactions, because it is not possible to nest RO transactions below RW transactions, exacerbating the issue described above. Fixes #7 en passant.
2019-10-24 17:56:45 +02:00
auto txn2 = std::move(txn);
{
auto cursor2 = std::move(cursor);
add range tests (lower_bound)
2019-01-05 14:40:04 +01:00
}
}
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
TEST_CASE("transaction inheritance and moving")
{
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
MDBDbi main = env.openDB("", MDB_CREATE);
MDBRWCursor cursor;
{
MDBRWTransaction txn = env.getRWTransaction();
MDBOutVal out;
REQUIRE(txn->get(main, "lmdb", out) == MDB_NOTFOUND);
// lets just keep this cursor to ensure that it invalidates
cursor = txn->getRWCursor(main);
txn->put(main, "bert", "hubert");
txn->put(main, "bertt", "1975");
txn->put(main, "berthubert", "lmdb");
txn->put(main, "bert1", "one");
txn->put(main, "beru", "not");
MDBROTransaction ro_txn(std::move(txn));
// despite being moved to an ro_txn (which normally commits instead of
// aborting by default)
}
Add CMake build system replacing Makefile * Allow building a shared library with proper exports * Remove bundled catch2 library in favor of searching for system-provided version * Adapt/fix tests and examples to latest changes * Fix several warnings
2022-01-30 00:05:02 +01:00
CHECK(!const_cast<const MDBRWCursor&>(cursor));
Hide MDB*Transaction behind a unique_ptr front This is to prevent the issue with Object Slicing. With the previous solution (where MDB*Transaction are normal objects), consider the following code: MDBRWTransaction txn = env.getRWTransaction(); //! Invalid: We explicitly break this move because it would be //! unsafe: // MDBROTransaction ro_txn(std::move(txn)); //! Valid, RW inherits from RO now, so we can bind an RO //! reference to an RW transaction. MDBROTransaction &ro_txn = txn; //! Dangerous!! MDBROTransaction ro_txn2(std::move(ro_txn)); The last move there breaks the semantics of the RW transaction which is bound to the reference ro_txn. It looses its RW cursors, which remain partly inside the txn instance. All kinds of weird and bad things can happen here. For instance, the ro_txn2 would go out of scope before the txn, calling the destructor MDBROTransaction destructor (which defaults to commit instead of abort!) and only freeing parts of the cursors. Only then the MDBRWTransaction destructor is called, which will free the cursors which belong to the RW transaction which has already been committed. The only safe way to prevent Object Slicing in this scenario I could come up with is to disallow moves of the objects altogether and instead use unique_ptr as front for them. This also removes an additional dynamic allocation per RW transaction (for the cursor vector), since the address of that vector is now constant over the lifetime of the transaction without indirection.
2019-10-26 11:42:38 +02:00
}
Implement support for nesting transactions RW transactions can have RW and RO transactions nested (although the RO transactions are really just disguised RW transactions, because LMDB does not support nesting real RO transactions to RW transactions). RO transactions can not be nested (again an LMDB limitation).
2019-10-26 12:07:03 +02:00
TEST_CASE("nested RW transactions", "[transactions]")
{
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
REQUIRE(1);
MDBDbi main = env.openDB("", MDB_CREATE);
/* bootstrap some data */
{
auto txn = env.getRWTransaction();
txn->put(main, "bert", "hubert");
txn->put(main, "bertt", "1975");
txn->put(main, "berthubert", "lmdb");
txn->put(main, "bert1", "one");
txn->put(main, "beru", "not");
txn->commit();
}
auto main_txn = env.getRWTransaction();
main_txn->del(main, "bertt", "1975");
MDBOutVal dummy{};
CHECK(main_txn->get(main, "bertt", dummy) == MDB_NOTFOUND);
{
auto sub_txn = main_txn->getRWTransaction();
CHECK(sub_txn->get(main, "berthubert", dummy) == 0);
sub_txn->del(main, "berthubert", "lmdb");
CHECK(sub_txn->get(main, "berthubert", dummy) == MDB_NOTFOUND);
}
/* check that subtransaction got rolled back */
CHECK(main_txn->get(main, "berthubert", dummy) == 0);
/* and that the main changes are still there */
CHECK(main_txn->get(main, "bertt", dummy) == MDB_NOTFOUND);
{
auto sub_txn = main_txn->getRWTransaction();
CHECK(sub_txn->get(main, "berthubert", dummy) == 0);
sub_txn->del(main, "berthubert", "lmdb");
CHECK(sub_txn->get(main, "berthubert", dummy) == MDB_NOTFOUND);
/* this time for real! */
sub_txn->commit();
}
CHECK(main_txn->get(main, "berthubert", dummy) == MDB_NOTFOUND);
CHECK(main_txn->get(main, "bertt", dummy) == MDB_NOTFOUND);
}
TEST_CASE("nesting RW -> RO", "[transactions]")
{
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
REQUIRE(1);
MDBDbi main = env.openDB("", MDB_CREATE);
/* bootstrap some data */
{
auto txn = env.getRWTransaction();
txn->put(main, "bert", "hubert");
txn->put(main, "bertt", "1975");
txn->put(main, "berthubert", "lmdb");
txn->put(main, "bert1", "one");
txn->put(main, "beru", "not");
txn->commit();
}
auto main_txn = env.getRWTransaction();
main_txn->del(main, "bertt", "1975");
MDBOutVal dummy{};
CHECK(main_txn->get(main, "bertt", dummy) == MDB_NOTFOUND);
{
MDBROTransaction sub_txn = main_txn->getROTransaction();
CHECK(sub_txn->get(main, "berthubert", dummy) == 0);
}
/* check that subtransaction got rolled back */
CHECK(main_txn->get(main, "berthubert", dummy) == 0);
/* and that the main changes are still there */
CHECK(main_txn->get(main, "bertt", dummy) == MDB_NOTFOUND);
{
auto sub_txn = main_txn->getRWTransaction();
CHECK(sub_txn->get(main, "berthubert", dummy) == 0);
sub_txn->del(main, "berthubert", "lmdb");
CHECK(sub_txn->get(main, "berthubert", dummy) == MDB_NOTFOUND);
{
MDBROTransaction sub_sub_txn = sub_txn->getROTransaction();
CHECK(sub_sub_txn->get(main, "berthubert", dummy) == MDB_NOTFOUND);
}
/* this time for real! */
sub_txn->commit();
}
CHECK(main_txn->get(main, "berthubert", dummy) == MDB_NOTFOUND);
CHECK(main_txn->get(main, "bertt", dummy) == MDB_NOTFOUND);
}
TEST_CASE("try to nest twice", "[transactions]")
{
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
REQUIRE(1);
MDBDbi main = env.openDB("", MDB_CREATE);
/* bootstrap some data */
{
auto txn = env.getRWTransaction();
txn->put(main, "bert", "hubert");
txn->put(main, "bertt", "1975");
txn->put(main, "berthubert", "lmdb");
txn->put(main, "bert1", "one");
txn->put(main, "beru", "not");
txn->commit();
}
auto main_txn = env.getRWTransaction();
main_txn->del(main, "bertt", "1975");
MDBOutVal dummy{};
CHECK(main_txn->get(main, "bertt", dummy) == MDB_NOTFOUND);
{
auto sub_txn = main_txn->getRWTransaction();
CHECK(sub_txn->get(main, "berthubert", dummy) == 0);
sub_txn->del(main, "berthubert", "lmdb");
CHECK(sub_txn->get(main, "berthubert", dummy) == MDB_NOTFOUND);
CHECK_THROWS_AS(
main_txn->getRWTransaction(),
std::runtime_error
);
}
}
TEST_CASE("transaction counter correctness for RW->RW nesting")
{
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
REQUIRE(1);
MDBDbi main = env.openDB("", MDB_CREATE);
Add CMake build system replacing Makefile * Allow building a shared library with proper exports * Remove bundled catch2 library in favor of searching for system-provided version * Adapt/fix tests and examples to latest changes * Fix several warnings
2022-01-30 00:05:02 +01:00
CPP_UTILITIES_UNUSED(main)
Implement support for nesting transactions RW transactions can have RW and RO transactions nested (although the RO transactions are really just disguised RW transactions, because LMDB does not support nesting real RO transactions to RW transactions). RO transactions can not be nested (again an LMDB limitation).
2019-10-26 12:07:03 +02:00
{
auto txn = env.getRWTransaction();
auto sub_txn = txn->getRWTransaction();
}
CHECK_NOTHROW(env.getRWTransaction());
CHECK_NOTHROW(env.getROTransaction());
}
TEST_CASE("transaction counter correctness for RW->RO nesting")
{
unlink("./tests");
MDBEnv env("./tests", MDB_NOSUBDIR, 0600);
REQUIRE(1);
MDBDbi main = env.openDB("", MDB_CREATE);
Add CMake build system replacing Makefile * Allow building a shared library with proper exports * Remove bundled catch2 library in favor of searching for system-provided version * Adapt/fix tests and examples to latest changes * Fix several warnings
2022-01-30 00:05:02 +01:00
CPP_UTILITIES_UNUSED(main)
Implement support for nesting transactions RW transactions can have RW and RO transactions nested (although the RO transactions are really just disguised RW transactions, because LMDB does not support nesting real RO transactions to RW transactions). RO transactions can not be nested (again an LMDB limitation).
2019-10-26 12:07:03 +02:00
{
auto txn = env.getRWTransaction();
auto sub_txn = txn->getROTransaction();
}
CHECK_NOTHROW(env.getRWTransaction());
CHECK_NOTHROW(env.getROTransaction());
}