Skip to content

Conversation

@kbohinski
Copy link
Contributor

What is the purpose of the change

This pull request is a small qol change that makes it easier for users to read the values of their accumulator(s).

Brief change log

  • Filter the value of the accumulator with toLocaleString

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): (yes / no) No
  • The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no) No
  • The serializers: (yes / no / don't know) No
  • The runtime per-record code paths (performance sensitive): (yes / no / don't know) No
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know) No
  • The S3 file system connector: (yes / no / don't know) No

Documentation

  • Does this pull request introduce a new feature? (yes / no) No
  • If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@greghogan
Copy link
Contributor

Is this valid if we have a non-numeric accumulator? Not sure if that is an issue.

@zentol
Copy link
Contributor

zentol commented Feb 7, 2019

I would like to understand what case we're trying to solve here. What locality-dependent component does a stringified number have? The only case that comes to my mind right now are periods vs. commas, but this wouldn't be addressed here.

Beyond that, accumulators don't impose an restriction on the value type, so albeit being admittedly a rare case we can't merge this.

FYI, the number filter will return en empty string for non-numeric values.

@zentol zentol closed this Mar 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants