zentol commented on code in PR #20757:
URL: https://github.com/apache/flink/pull/20757#discussion_r966808144


##########
flink-core/src/main/java/org/apache/flink/api/connector/source/lib/util/IteratorSourceReaderBase.java:
##########
@@ -0,0 +1,164 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.flink.api.connector.source.lib.util;
+
+import org.apache.flink.annotation.Public;
+import org.apache.flink.api.connector.source.SourceReader;
+import org.apache.flink.api.connector.source.SourceReaderContext;
+import org.apache.flink.core.io.InputStatus;
+
+import javax.annotation.Nullable;
+
+import java.util.ArrayDeque;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Queue;
+import java.util.concurrent.CompletableFuture;
+
+import static org.apache.flink.util.Preconditions.checkNotNull;
+
+/**
+ * A {@link SourceReader} that returns the values of an iterator, supplied via 
an {@link
+ * IteratorSourceSplit}.
+ *
+ * <p>The {@code IteratorSourceSplit} is also responsible for taking the 
current iterator and
+ * turning it back into a split for checkpointing.
+ *
+ * @param <E> The type of events returned by the reader.
+ * @param <IterT> The type of the iterator that produces the events. This type 
exists to make the
+ *     conversion between iterator and {@code IteratorSourceSplit} type safe.
+ * @param <SplitT> The concrete type of the {@code IteratorSourceSplit} that 
creates and converts
+ *     the iterator that produces this reader's elements.
+ */
+@Public
+abstract class IteratorSourceReaderBase<
+                E, O, IterT extends Iterator<E>, SplitT extends 
IteratorSourceSplit<E, IterT>>
+        implements SourceReader<O, SplitT> {
+
+    /** The context for this reader, to communicate with the enumerator. */
+    protected final SourceReaderContext context;
+
+    /** The availability future. This reader is available as soon as a split 
is assigned. */
+    protected CompletableFuture<Void> availability;
+
+    /**
+     * The iterator producing data. Non-null after a split has been assigned. 
This field is null or
+     * non-null always together with the {@link #currentSplit} field.
+     */
+    @Nullable protected IterT iterator;

Review Comment:
   > Is this more about having methods like getIterator() defined in another 
interface rather than exposing protected fields directly?
   
   Not really. That's just another flavor of the same problem. (Probably a 
_better_ flavor, but still)
   
   > This is very similar to the design of the SourceReaderBase that is also 
part of the new Sink API. 
   
   I dislike that as well :)
   
   > Is not SourceReader such a well-defined interface?
   
   The SourceReader is an interface for what a `SourceReader` does. It has no 
bearing on what behavior a _sub-class of the IteratorSourceReaderBase_ should 
be able to customize.
   
   > Could you give a sketch
   
   Yes! 
https://github.com/zentol/flink/commit/[aa071987c763f05420f8a0832bb556eeb46b8c6f](https://github.com/apache/flink/pull/20757#discussion_r966808144)
   
   I hope this sketch also highlights why I dislike having so much exposed to 
sub-classes; you easily end up mixing responsibilities. There's no good reason 
for why the entire `pollNext()` routine was handle be the sub-class.
   
   Beyond that, here are questions I thought about when looking at it:
   * Why should a sub class have control over the iterator?
   * Why should it be able to ignore elements, or entire splits?
   * Why should it be able to override the `availability` future (bricking the 
source when don't at the wrong time)?
   
   You end up short-cutting any thought about "what custom behavior might 
someone want and how can we support that _safely_", and in the process end up 
adding a whole bunch of traps and potential for contracts to be broken.
   
   Note that in the sketch the sub-class ends up being a bit pointless; as we'd 
be better of just merging the 2 classes at this time.



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to