[ 
https://issues.apache.org/jira/browse/FLINK-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251568#comment-15251568
 ] 

ASF GitHub Bot commented on FLINK-3798:
---------------------------------------

Github user gyfora commented on a diff in the pull request:

    https://github.com/apache/flink/pull/1918#discussion_r60544472
  
    --- Diff: 
flink-contrib/flink-statebackend-rocksdb/src/main/java/org/apache/flink/contrib/streaming/state/RocksDBValueState.java
 ---
    @@ -64,7 +64,7 @@
         * @param stateDesc The state identifier for the state. This contains 
name
         *                           and can create a default state value.
         */
    -   RocksDBValueState(ColumnFamilyHandle columnFamily,
    +   public RocksDBValueState(ColumnFamilyHandle columnFamily,
    --- End diff --
    
    The reason why I made the state constructors public so if you sublcass the 
RocksDBStatebackend you can still manually instantiate them. You wouldnt be 
able to call the protected constructor from your package though. 
    
    It's no biggie, I can change it if you still think its better as protected.


> 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
>            Assignee: 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)

Reply via email to