[
https://issues.apache.org/jira/browse/FLINK-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250554#comment-15250554
]
ASF GitHub Bot commented on FLINK-3798:
---------------------------------------
GitHub user gyfora opened a pull request:
https://github.com/apache/flink/pull/1918
[FLINK-3798] [streaming] Clean up RocksDB backend field/method access
The RocksDB state backend uses a lot package private methods and fields
which makes it very hard to subclass the different parts for added
functionality. I think these should be protected instead.
Also the AbstractRocksDBState declares some methods final when there are
use-cases when a subclass migh want to call them.
Just to give you an example I am creating a version of the value state
which would keep a small cache on heap. For this it would be enough to subclass
the RockDBStateBackend and RocksDBVAlue state classes if the above mentioned
changes were made. Now I have to use reflection to access package private
fields and actually copy classes due to final methods.
Activity
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gyfora/flink rocks-access
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/flink/pull/1918.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1918
----
commit a1e323650bd5f603fbf3809fe1fe901cbab1a56b
Author: Gyula Fora <[email protected]>
Date: 2016-04-20T19:33:30Z
[FLINK-3798] [streaming] Clean up RocksDB backend field/method access
----
> Clean up RocksDB state backend access modifiers
> -----------------------------------------------
>
> Key: FLINK-3798
> URL: https://issues.apache.org/jira/browse/FLINK-3798
> Project: Flink
> Issue Type: Improvement
> Components: Streaming Connectors
> Reporter: Gyula Fora
> Priority: Minor
>
> The RocksDB state backend uses a lot package private methods and fields which
> makes it very hard to subclass the different parts for added functionality. I
> think these should be protected instead.
> Also the AbstractRocksDBState declares some methods final when there are
> use-cases when a subclass migh want to call them.
> Just to give you an example I am creating a version of the value state which
> would keep a small cache on heap. For this it would be enough to subclass the
> RockDBStateBackend and RocksDBVAlue state classes if the above mentioned
> changes were made. Now I have to use reflection to access package private
> fields and actually copy classes due to final methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
