Github user HyukjinKwon commented on a diff in the pull request:
    --- Diff: 
external/avro/src/main/scala/org/apache/spark/sql/avro/package.scala ---
    @@ -0,0 +1,39 @@
    + * 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
    + *
    + *
    + *
    + * 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
    +package object avro {
    +  /**
    +   * Adds a method, `avro`, to DataFrameWriter that allows you to write 
avro files using
    +   * the DataFileWriter
    +   */
    +  implicit class AvroDataFrameWriter[T](writer: DataFrameWriter[T]) {
    +    def avro: String => Unit = writer.format("avro").save
    --- End diff --
    In that case, can we move this into DataFrameReader and DataFrameWriter for 
Python and Java usages too?
    I think this was just a workaround to resemble Spark 2.0.0's API shape. 
spark-avro as a thridparty would probably keep source and binary compatibility 
but here I think we don't keep them although we will probably keep the 
behaviours. So, I think it's better to minimise the exposed APIs when we are in 
    To me, I can't see any particular advantage of keeping it on the other hand 
as implicit here.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to