Github user tzulitai commented on a diff in the pull request:
https://github.com/apache/flink/pull/5885#discussion_r184694977
--- Diff:
flink-state-backends/flink-statebackend-rocksdb/src/main/java/org/apache/flink/contrib/streaming/state/RocksDBKeyedStateBackend.java
---
@@ -1116,148 +1115,177 @@ private void
restoreKeyGroupsShardWithTemporaryHelperInstance(
//
------------------------------------------------------------------------
/**
- * Creates a column family handle for use with a k/v state. When
restoring from a snapshot
- * we don't restore the individual k/v states, just the global RocksDB
database and the
- * list of column families. When a k/v state is first requested we
check here whether we
- * already have a column family for that and return it or create a new
one if it doesn't exist.
+ * Registers a k/v state information, which includes its state id,
type, RocksDB column family handle, and serializers.
*
- * <p>This also checks whether the {@link StateDescriptor} for a state
matches the one
- * that we checkpointed, i.e. is already in the map of column families.
+ * When restoring from a snapshot, we donât restore the individual
k/v states, just the global RocksDB database and
+ * the list of k/v state information. When a k/v state is first
requested we check here whether we
+ * already have a registered entry for that and return it (after some
necessary state compatibility checks)
+ * or create a new one if it does not exist.
*/
- @SuppressWarnings("rawtypes, unchecked")
- protected <N, S> ColumnFamilyHandle getColumnFamily(
- StateDescriptor<?, S> descriptor, TypeSerializer<N>
namespaceSerializer) throws IOException, StateMigrationException {
+ private Tuple2<ColumnFamilyHandle,
RegisteredKeyedBackendStateMetaInfo<?, ?>> tryRegisterKvStateInformation(
--- End diff --
I did not go with this approach because of the extra tuples introduced.
Though, TBH, I wasn't sure which was the better approach, this or the one
you pointed out.
I would not be against this version.
---
