Skip to content

[BEAM-7554] Add MillisInstant logical type to replace DATETIME - #11456

Closed
TheNeuralBit wants to merge 22 commits into
apache:masterfrom
TheNeuralBit:deprecate-datetime-2
Closed

[BEAM-7554] Add MillisInstant logical type to replace DATETIME #11456
TheNeuralBit wants to merge 22 commits into
apache:masterfrom
TheNeuralBit:deprecate-datetime-2

Conversation

@TheNeuralBit

@TheNeuralBitTheNeuralBit commented Apr 17, 2020

Copy link
Copy Markdown
Member

This PR adds a MillisInstant logical type, and replaces all usages of the primitive DATETIME type with it.

MillisInstant mirrors the NanosInstant type. It uses org.joda.time.Instant rather than java.time.Instant for consistency with DATETIME, and it is backed by an INT64 representing the number of milliseconds since the epoch.

The majority of the changes in this PR are relatively trivial, but there are a few significant (and some potentially controversial) ones:

  • Updates the datetime getter/setter functions generated in ByteBuddyUtils to produce and consume instances of Long rather than Instant. This is necessary because these functions are expected to produce/consume the base type for logical types.
  • Updates all joda time literals in schema inference tests so they specify a timezone.
  • Throughout the SQL module I've replaced references to getBaseValue with getValue. Previously the only logical types used in SQL were PassThroughLogicalType instances, where the input type and base type were the same.

Changes that are not currently included in this PR but we might consider:

  • Replace all references to DateTime (addDateTimeField, addDateTimeValue, ..) with Instant, and deprecate or remove the DateTime references.

Post-Commit Tests Status (on master branch)

LangSDKApexDataflowFlinkGearpumpSamzaSpark
GoBuild Status------Build Status------Build Status
JavaBuild StatusBuild StatusBuild Status
Build Status
Build Status
Build Status
Build Status
Build StatusBuild StatusBuild Status
Build Status
Build Status
PythonBuild Status
Build Status
Build Status
Build Status
---Build Status
Build Status
Build Status
Build Status
Build Status
------Build Status
XLang---------Build Status------Build Status

Pre-Commit Tests Status (on master branch)

---JavaPythonGoWebsite
Non-portableBuild StatusBuild Status
Build Status
Build StatusBuild Status
Portable---Build Status------

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

@TheNeuralBit

Copy link
Copy Markdown
MemberAuthor

Run SQL PostCommit

@TheNeuralBitTheNeuralBit changed the title WIP: [BEAM-7554] Add MillisInstant logical type to replace DATETIME [BEAM-7554] Add MillisInstant logical type to replace DATETIME Apr 22, 2020
FLOAT,
DOUBLE,
STRING, // String.
DATETIME, // Date and time.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little worried about this. Empirically many users are using schemas. Maybe we should start off by leaving DATETIME around and remove it later in another PR?

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we could deprecate it for a release or two before removing. Would we also need to keep support for the primitive DATETIME in IOs and SQL? I'd need to think about how that transition would work.

: combined.aggregateFieldBaseValue(
inputs.get(0), combineFn, fieldAggregation.outputField);
? byFields.aggregateField(inputs.get(0), combineFn, fieldAggregation.outputField)
: combined.aggregateField(inputs.get(0), combineFn, fieldAggregation.outputField);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I agree with this change. I think it's important that SQL work over user logical types by interpreting it as the base value. The user writing the SQL statement usually understands the base type of their logical type, and can write the SQL statement appropriately. This will break that.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adding the option for SqlTransform to convert unknown logical types to their base type at the input? I think that behavior would be effectively the same

Expressions.constant(index),
Expressions.constant(convertTo)),
convertTo);
Expressions.call(expression, "getValue", Expressions.constant(index)), convertTo);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the same concern with this change.


/** A timestamp represented as milliseconds since the epoch. */
public class MillisInstant extends MillisType<ReadableInstant> {
public static final String IDENTIFIER = "beam:logical_type:millis_instant:v1";

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reuvenlax what do you think about making this type (and maybe NanosInstant as well) parameterized by timezone?

The arrow approach seems useful: un-specified timezone indicates time-zone naive (e.g. joda time Instant), otherwise time zone parameter should reference a value in tzdata (and would map to joda time DateTime).

cc: @alexvanboxel

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A timestamp type seems like it's by definition time-zone agnostic. If we want a datetime type, that should be a different type.

@robinyqiu

Copy link
Copy Markdown
Contributor

cc: @robinyqiu@ZijieSong946

@stale

staleBot commented Sep 5, 2020

Copy link
Copy Markdown

This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@beam.apache.org list. Thank you for your contributions.

@stalestaleBot added the stale label Sep 5, 2020
@stale

staleBot commented Sep 12, 2020

Copy link
Copy Markdown

This pull request has been closed due to lack of activity. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TheNeuralBit@robinyqiu@reuvenlax