[GitHub] spark pull request #21192: [SPARK-24118][SQL] Flexible format for the lineSe...

[MaxGekk <gi...@git.apache.org>]

Github user MaxGekk commented on a diff in the pull request:

    https://github.com/apache/spark/pull/21192#discussion_r185197844
  
    --- Diff: sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/json/JSONOptions.scala ---
    @@ -120,8 +120,26 @@ private[sql] class JSONOptions(
           enc
       }
     
    -  val lineSeparatorInRead: Option[Array[Byte]] = lineSeparator.map { lineSep =>
    -    lineSep.getBytes(encoding.getOrElse("UTF-8"))
    +  /**
    +   * A sequence of bytes between two consecutive json records in read.
    +   * Format of the `lineSep` option is:
    +   *   selector (1 char) + separator spec (any length) | sequence of chars
    +   *
    +   * Currently the following selectors are supported:
    +   * - 'x' + sequence of bytes in hexadecimal format. For example: "x0a 0d".
    --- End diff --
    
    Your approach looks interesting but your PRs https://github.com/apache/spark/pull/20125 and https://github.com/apache/spark/pull/16611 stuck. Are there any specific reasons for that?
    
    > Maybe, we could try a similar approach.
    
    We could but it requires extension of public API more widely than it is needed by this changes. Do you think it makes sense? Actually I would consider `lineSep` as a string in JSON format like:
    
    ```scala
    .option("lineSep", "[0x00, 0x0A, 0x00, 0x0D]")
    ```
    or
    ```scala
    .option("lineSep", """{"sep": "\r\n", "encoding": "UTF-16LE"}""")
    ```
    but for regular cases of simple `lineSep`, this approach looks pretty redundant:
    ```
    .option("lineSep", ",") vs .option("lineSep", """{"sep": ","}""")
    ``` 


---

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