Github user jose-torres commented on a diff in the pull request:

    https://github.com/apache/spark/pull/20689#discussion_r171332700
  
    --- Diff: 
sql/core/src/main/java/org/apache/spark/sql/sources/v2/reader/ContinuousDataReaderFactory.java
 ---
    @@ -0,0 +1,38 @@
    +/*
    + * 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.spark.sql.sources.v2.reader;
    +
    +import org.apache.spark.annotation.InterfaceStability;
    +import org.apache.spark.sql.sources.v2.reader.streaming.PartitionOffset;
    +
    +/**
    + * A mix-in interface for {@link DataReaderFactory}. Continuous data 
reader factories can
    + * implement this interface to provide creating {@link DataReader} with 
particular offset.
    + */
    +@InterfaceStability.Evolving
    +public interface ContinuousDataReaderFactory<T> extends 
DataReaderFactory<T> {
    +  /**
    +   * Create a DataReader with particular offset as its startOffset.
    +   *
    +   * @param offset offset want to set as the DataReader's startOffset.
    +   */
    +  default DataReader<T> createDataReaderWithOffset(PartitionOffset offset) 
{
    +    throw new IllegalStateException(
    --- End diff --
    
    I don't know if we want a default here - it seems like subclasses should 
always be able to provide an implementation, and thus that we should always 
require them to.


---

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org

Reply via email to