[GitHub] flink pull request #5536: [FLINK-8714][Documentation] Added either charsetNa...

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

GitHub user michalklempa opened a pull request:

    https://github.com/apache/flink/pull/5536

    [FLINK-8714][Documentation] Added either charsetName) or "utf-8" value in examples of readTextFile

    ## What is the purpose of the change
    When a newcomer (like me), goes through the docs, there are several places where examples encourage to read the input data using the env.readTextFile() method.
    
    This method variant does not take a second argument - character set (see https://ci.apache.org/projects/flink/flink-docs-release-1.4/api/java/org/apache/flink/streaming/api/environment/StreamExecutionEnvironment.html#readTextFile-java.lang.String-). This versoin relies (according to Javadoc) on " The file will be read with the system's default character set. "
    *(For example: This pull request makes task deployment go through the blob server, rather than through RPC. That way we avoid re-transferring them on each deployment (during recovery).)*
    
    Fixing this in documentation by providing charsetName in examples where the API is described and "utf-8" as second argument in programming examples. This should help others not to forget about the need to specify a charset programmatically, if they want to avoid non-deterministic behavior depending on environment.
    
    ## Brief change log
    
    ## Verifying this change
    
    This change is a trivial rework of documentation without any test coverage.
    
    ## Does this pull request potentially affect one of the following parts:
    
      - Dependencies (does it add or upgrade a dependency): no
      - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: no
      - The serializers: no
      - The runtime per-record code paths (performance sensitive): no
      - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
      - The S3 file system connector: no
    
    ## Documentation
    
      - Does this pull request introduce a new feature? no
      - If yes, how is the feature documented? not applicable


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/michalklempa/flink FLINK-8714_readTextFile_charset_version

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/flink/pull/5536.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #5536
    
----
commit 221684da5b564b21c1e0cc99e823c18939c0ca91
Author: Michal Klempa <mi...@...>
Date:   2018-02-20T13:50:30Z

    FLINK-8714 added either env.readTextFile(pathToFile, charsetName) where the API is described or readTextFile(path/to/file, utf-8)  where API is shown as example

----


---

[GitHub] flink issue #5536: [FLINK-8714][Documentation] Added either charsetName) or ...

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

Github user michalklempa commented on the issue:

    https://github.com/apache/flink/pull/5536
  
    @zentol Thanks, done.


---

[GitHub] flink issue #5536: [FLINK-8714][Documentation] Added either charsetName) or ...

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

Github user michalklempa commented on the issue:

    https://github.com/apache/flink/pull/5536
  
    Unrelated test https://travis-ci.org/apache/flink/jobs/343906340#L5636 failing.


---

[GitHub] flink issue #5536: [FLINK-8714][Documentation] Added either charsetName) or ...

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

Github user StephanEwen commented on the issue:

    https://github.com/apache/flink/pull/5536
  
    Sorry, I think the JavaDoc comment that triggered this change was actually incorrect in the first place.
    
    By default, the read methods always use "UTF-8" rather than the system default charset, so it is actually not non-deterministic.
    
    I would personally vote fix the javadoc and other docs that incorrectly claim this is using the system-dependent charset, and leave the other docs as they are (not explicitly pass the same charset name that is anyways passed, makes it simpler).


---