While `delete rocks_ptr` is a deterministic operation in C++, the Python analogue `del rocks_handle` is not – disposal and finalization of the Rocks database are entirely dependent on the Python garbage collector (q.v. the `python-rocksdb` tests themselves, which call `gc.collect()` after `del rocks_handle` to attempt to force the destructor to run). This change exposes a method to trigger the destruction of the underlying Rocks database pointer (deterministic!) through the Python Rocks handle; existing code will not need to be changed, as the Python object destructor (non-deterministic!) will now call this method.
This is the second revision of this PR – it resolves the first revision, #39.
Add support for Column Families in a runtime safe way.
Add unittests to test functionality
Insure all unittests are passing.
Cleaned up unittests to not use a fixed directory in tmp, but use tempfile
On delete rocksdb waits for the background thread to finish.
However the background threads needs the GIL to execute python-code
(for example comparator)
=>
* main thread has GIL
* main thread waits for background thread
* background thread tries to get GIL
which means deadlock
For better logging I'm going to inject the rocksdb info_logger into the C++ Wrapper classes
=> The classes on the options object have a member to a DB specific logger
=> This c++ classes can only belong to a SINGLE db
=> For simplicity make this requirement also for the options object itself
The cyclic garbage collector may choose this snappshot object to break the
cycle. In that case tp_clear will remove the reference to self.db.
So if __dealloc__ of the snapshot is called, self.db is not valid anymore
