Added support for column families #39
Conversation
|
@stephan-hof could you please merge this? (@grove thanks for doing the work!) |
|
The problem with this implementation of column families is that in the latest rocksdb holding a handle to a column family and closing the DB will cause an assert failure in rocksdb. While this behavior is acceptable in C++. It is unacceptable in python that anything would ever cause a segfault. My Suggestion is that instead of having a object that holds onto column families that you just return a str that the db object knows how to turn back into a handle. So in the db dealloc it can clear its mapping from str to handle and no abort is possible. |
|
Well spotted. I agree. I've also noticed a related issue[1]. If a column family is deleted and then later some other thread tries to use it, then the database enters read-only mode(!). In this case it is really important to manage the life-cycle of the column family handles. I'm not sure if pyrocksdb have an API for closing the DB right now. Maybe it's relying on the garbage collector to kick in for that to happen automatically? |
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, stephan-hof#39.
This should fix issue #34.