Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp Data Model #1121

Merged
merged 16 commits into from
Jul 11, 2023
Merged

Timestamp Data Model #1121

merged 16 commits into from
Jul 11, 2023

Conversation

yliuuuu
Copy link
Contributor

@yliuuuu yliuuuu commented Jun 13, 2023

Relevant Issues

Description

This PR is a POC on Timestamp Type.
This PR covers the Timestamp Data Model, and enable timestamp constructor in Parser.
This PR does not cover any aspect of evaluation yet, as covering those will create too big a diff for reviewer.

Other Information

  • Updated Unreleased Section in CHANGELOG: [YES/NO]

    • Yes.
  • Any backward-incompatible changes? [YES/NO]

    • Not yet, but will be once we gets to the compiler/evaluator.
  • Any new external dependencies? [YES/NO]

    • No.
  • Do your changes comply with the Contributing Guidelines
    and Code Style Guidelines?

  • Yes.

License Information

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@yliuuuu yliuuuu marked this pull request as ready for review June 22, 2023 21:36
@yliuuuu yliuuuu changed the title PoC on timestamp Timestamp Data Model Jun 22, 2023
CHANGELOG.md Show resolved Hide resolved
@github-actions
Copy link

github-actions bot commented Jun 22, 2023

Conformance comparison report

Base (2283db5) 6ea7b97 +/-
% Passing 92.40% 92.40% 0.00%
✅ Passing 5376 5376 0
❌ Failing 442 442 0
🔶 Ignored 0 0 0
Total Tests 5818 5818 0

Number passing in both: 5376

Number failing in both: 442

Number passing in Base (2283db5) but now fail: 0

Number failing in Base (2283db5) but now pass: 0

@codecov-commenter
Copy link

codecov-commenter commented Jun 22, 2023

Codecov Report

Patch coverage: 85.71% and project coverage change: +0.10 🎉

Comparison is base (2283db5) 73.19% compared to head (f3b48e7) 73.30%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #1121      +/-   ##
============================================
+ Coverage     73.19%   73.30%   +0.10%     
- Complexity     2376     2400      +24     
============================================
  Files           237      238       +1     
  Lines         17261    17444     +183     
  Branches       3133     3158      +25     
============================================
+ Hits          12635    12787     +152     
- Misses         3653     3674      +21     
- Partials        973      983      +10     
Flag Coverage Δ
CLI 14.28% <ø> (ø)
EXAMPLES 80.28% <ø> (ø)
LANG 79.15% <85.71%> (+0.04%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...kotlin/org/partiql/lang/eval/EvaluatingCompiler.kt 80.70% <0.00%> (-0.14%) ⬇️
...iql/lang/eval/physical/PhysicalPlanCompilerImpl.kt 83.86% <0.00%> (-0.26%) ⬇️
.../eval/visitors/SubqueryCoercionVisitorTransform.kt 96.70% <0.00%> (-2.19%) ⬇️
...n/org/partiql/lang/prettyprint/ASTPrettyPrinter.kt 77.91% <0.00%> (-0.15%) ⬇️
...org/partiql/lang/prettyprint/QueryPrettyPrinter.kt 78.37% <0.00%> (-0.29%) ⬇️
...artiql/lang/types/PartiqlPhysicalTypeExtensions.kt 90.00% <0.00%> (-2.76%) ⬇️
...tlin/org/partiql/lang/syntax/util/DateTimeUtils.kt 79.54% <79.54%> (ø)
.../org/partiql/lang/syntax/impl/PartiQLPigVisitor.kt 89.47% <88.32%> (+0.16%) ⬆️
...c/main/kotlin/org/partiql/lang/errors/ErrorCode.kt 85.21% <100.00%> (+0.24%) ⬆️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Copy link
Member

@johnedquinn johnedquinn left a comment

Choose a reason for hiding this comment

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

This is an awesome piece of work. Left some comments -- the only two files I have yet to go through are TimestampTests and PartiQLParserDateTimeTests.

/**
* Counting the time escaped from midnight 00:00:00 in seconds ( fraction included)
*/
val elapsedSecond: BigDecimal by lazy {
Copy link
Member

Choose a reason for hiding this comment

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

internal

Copy link
Member

Choose a reason for hiding this comment

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

And, roundToPrecision can use this value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This may not need to be internal as this is a commonly exposed property in java's time package.
Maybe keep it as is and wait for the evaluation PR to confirm?

partiql-ast/src/main/pig/partiql.ion Outdated Show resolved Hide resolved
@yliuuuu yliuuuu requested a review from johnedquinn July 5, 2023 20:00
Copy link
Contributor Author

@yliuuuu yliuuuu left a comment

Choose a reason for hiding this comment

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

Address feedback

/**
* Counting the time escaped from midnight 00:00:00 in seconds ( fraction included)
*/
val elapsedSecond: BigDecimal by lazy {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This may not need to be internal as this is a commonly exposed property in java's time package.
Maybe keep it as is and wait for the evaluation PR to confirm?

}

val epochMillis: BigDecimal by lazy {
epochSecond.movePointRight(3)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This should be safe.

Copy link
Contributor

@RCHowell RCHowell left a comment

Choose a reason for hiding this comment

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

Overall very impressive. This is a ton of work. Just a few comments as I took a cursory review. I will look more into this tomorrow. Thank you.

Comment on lines +139 to +152
public override val year: Int?
get() = null

/**
* Month field for [Time] is always null
*/
public override val month: Int?
get() = null

/**
* Day field for [Time] is always null
*/
public override val day: Int?
get() = null
Copy link
Contributor

Choose a reason for hiding this comment

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

Why getters? Can you just assign null?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Property initializers are not allowed in interfaces.

Comment on lines +332 to +348
public abstract class DateImpl : Date, Comparable<Date> {
public final override fun equals(other: Any?): Boolean {
if (this === other) return true
if (other?.javaClass != javaClass) return false
other as DateImpl
if (this.year != other.year) return false
if (this.month != other.month) return false
if (this.day != other.day) return false
return true
}

public final override fun hashCode(): Int =
year.hashCode() + month.hashCode() + day.hashCode()

public final override fun toString(): String =
"${this.javaClass.simpleName}(year=$year, month=$month, day=$day)"
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not make Date the abstract class with these default implementations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The original thought was to accommodate the possibility of having to implement different date system. Maybe I am overcomplicating this stuff and we would never need this...

Copy link
Member

@johnedquinn johnedquinn left a comment

Choose a reason for hiding this comment

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

Wow -- this is quite a lot of work. Great job. As for the creation of low/high precision datetimes, I didn't find anything wrong. I had some questions offline, but it all looked good.

I had one small nit about a function name and a test method, but beyond that, it LGTM.

* Returns a [Date] value with the specified number of months added.
* [years] can be negative.
*/
public fun plusYear(years: Long): Date
Copy link
Member

Choose a reason for hiding this comment

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

Nit -- plusYears

Copy link
Member

Choose a reason for hiding this comment

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

Also, specified number of years added in the KDoc.

Comment on lines 589 to 599
// negative epoch
// May be Ion has a bug?
// Expected epoch in Millis : -23225270400000,
// Actual epoch in Millis : -23225875200000
// SuccessCaseWithNoTimeZone(
// 1234, 1, 1, 0,0, BigDecimal.valueOf(0,3), 0,
// Timestamp.of(
// DateTimeValue.date(1234, 1, 1),
// DateTimeValue.time(0,0, BigDecimal.valueOf(0,0), )
// ),
// ),
Copy link
Member

Choose a reason for hiding this comment

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

While the matching SuccessCaseWithUnknownTimeZone fails -- would this one also fail? This specific test case shouldn't be comparing Ion values if I'm reading this correctly.

@yliuuuu yliuuuu requested a review from johnedquinn July 11, 2023 22:15
@yliuuuu yliuuuu merged commit 44e8a8d into main Jul 11, 2023
10 checks passed
@yliuuuu yliuuuu deleted the TimestampType branch July 11, 2023 22:21
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.

4 participants