flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-3798) Clean up RocksDB state backend access modifiers
Date Thu, 21 Apr 2016 08:41:25 GMT

    [ 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:

    --- 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

View raw message