spark-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From HyukjinKwon <...@git.apache.org>
Subject [GitHub] spark pull request #21742: [SPARK-24768][SQL] Have a built-in AVRO data sour...
Date Wed, 11 Jul 2018 08:11:43 GMT
Github user HyukjinKwon commented on a diff in the pull request:

    https://github.com/apache/spark/pull/21742#discussion_r201599624
  
    --- 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
    + *
    + *    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
    +
    +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 doubt.
    
    To me, I can't see any particular advantage of keeping it on the other hand as implicit
here.



---

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


Mime
View raw message