-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement missing compactrangeoptions from Java API #10880
Implement missing compactrangeoptions from Java API #10880
Conversation
23c8213
to
6620498
Compare
6620498
to
3acc39c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@jay-zhuang (cc @ajkr) could we get this one merged please? |
@siying has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
f11be9b
to
2b69eae
Compare
@alanpaxton has updated the pull request. You must reimport the pull request before landing. |
@ajkr has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
2b69eae
to
99c9b4f
Compare
@alanpaxton has updated the pull request. You must reimport the pull request before landing. |
@alanpaxton Please rebase |
deal with “not set” values and finish tests
Add CompactRangeOptions$Timestamp support in portal.h to construct new timestamp to return. Adapt JNI method signature to form returning Timestamp. Rename timestamp param for consistency. # Conflicts: # java/rocksjni/portal.h
We changed the handle to return an object containing ROCKSDB_NAMESPACE::CompactRangeOptions at (probably) 0-offset, rather than a ROCKSDB_NAMESPACE::CompactRangeOptions. Casting handle to ROCKSDB_NAMESPACE::CompactRangeOptions worked (i.e. old methods didn’t have to be changed), but really that’s a minefield and the correct answer is to cast to the correct type (Java_org_rocksdb_CompactRangeOptions) and then use the ROCKSDB_NAMESPACE::CompactRangeOptions field in that. # Conflicts: # java/rocksjni/compact_range_options.cc
99c9b4f
to
2bccb06
Compare
@alanpaxton has updated the pull request. You must reimport the pull request before landing. |
@anand1976 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@anand1976 merged this pull request in 93e0715. |
Add the following missing options to
src/main/java/org/rocksdb/CompactRangeOptions.java
and injava/rocksjni/options.cc
in RocksJava.For the descriptions and API see the C++ file
include/rocksdb/options.h
, specifically the structCompactRangeOptions
We changed the handle to return an object (of class
Java_org_rocksdb_CompactRangeOptions
) containing aROCKSDB_NAMESPACE::CompactRangeOptions
at (almost certainly) 0-offset, rather than a rawROCKSDB_NAMESPACE::CompactRangeOptions
.The
Java_org_rocksdb_CompactRangeOptions
contains as supplementary fields objects (std::string, std::atomic) which are passed as pointers to theROCKSDB_NAMESPACE::CompactRangeOptions
and which must therefore live for as long as theROCKSDB_NAMESPACE::CompactRangeOptions
. By placing them in aJava_org_rocksdb_CompactRangeOptions
we achieve this.Because the field offset of the
ROCKSDB_NAMESPACE::CompactRangeOptions
member is (very probably) 0, casting the handle to ROCKSDB_NAMESPACE::CompactRangeOptions works (i.e. old methods didn’t have to be changed), but really that’s a minefield and the correct answer is to cast to the correct type (Java_org_rocksdb_CompactRangeOptions) and then use the ROCKSDB_NAMESPACE::CompactRangeOptions field in that. So the get/set methods for existing parameters have this change.Testing
We added unit tests for getting and setting the newly implemented fields to
CompactRangeOptionsTest