ableegoldman commented on code in PR #18275:
URL: https://github.com/apache/kafka/pull/18275#discussion_r1893478556
##########
streams/src/main/java/org/apache/kafka/streams/state/internals/RocksDBGenericOptionsToDbOptionsColumnFamilyOptionsAdapter.java:
##########
@@ -571,17 +570,6 @@ public long dbWriteBufferSize() {
return dbOptions.dbWriteBufferSize();
}
- @Override
- public Options setAccessHintOnCompactionStart(final AccessHint accessHint)
{
- dbOptions.setAccessHintOnCompactionStart(accessHint);
- return this;
- }
-
- @Override
- public AccessHint accessHintOnCompactionStart() {
- return dbOptions.accessHintOnCompactionStart();
Review Comment:
Yeah this drives me crazy. Personally I think it's ok to bite the bullet on
this one but let's definitely come up with a strategy for this going forward.
I'd say a good compromise is to meet in the middle and do both, that is,
publish an official policy for RocksDB APIs which says there is no guarantee of
the usual one-year deprecation & only major version removal, and any
deprecations are best-effort. I'm less worried about the deprecations and more
about restricting our ability to upgrade rocksdb to only major releases.
At the same time, I think we can and should do better. I like the idea of
looking ahead at each new RocksDB release to mark any changed or removed APIs
exposed to our users so we can deprecate them ASAP. We can hash out the details
of how often and how to share this responsibility later (for example maybe this
should be one of the Streams RM responsibilities, to look for upcoming API
changes in future rocks and make sure they get deprecated in that release
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
