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

Use timestamp precision 3 in CTAS in MySQL #7166

Merged
merged 2 commits into from
Mar 8, 2021

Conversation

jirassimok
Copy link
Member

This addresses #6909.

The first two commits are minor refactors to the MySql timestamp tests so they are organized in a way that separates CTAS failures from other failures.

@cla-bot cla-bot bot added the cla-signed label Mar 5, 2021
Copy link
Member

@hashhar hashhar left a comment

Choose a reason for hiding this comment

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

Thansk for the test method renames. It's much clearer now.

Some changes requested.

{
Session session = Session.builder(getSession())
.setTimeZoneKey(TimeZoneKey.getTimeZoneKey(sessionZone.getId()))
.build();

// TODO merge this into the above SqlDataTypeTest once we support writing and reading timestamps with precisions other than 3 (TODO https://github.com/trinodb/trino/issues/6910)
Copy link
Member

Choose a reason for hiding this comment

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

Move this comment into the javadoc now. And change into the above to testTimestampFromTrino.

Copy link
Member Author

Choose a reason for hiding this comment

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

Based on this comment, I've dropped this comment entirely. We don't need it to remind us that we'll need more tests when we support more precisions.

@@ -352,7 +352,7 @@ public WriteMapping toWriteMapping(ConnectorSession session, Type type)
}
if (TIMESTAMP_MILLIS.equals(type)) {
// TODO use `timestampWriteFunction` (https://github.com/trinodb/trino/issues/6910)
return WriteMapping.longMapping("datetime", timestampWriteFunctionUsingSqlTimestamp(TIMESTAMP_MILLIS));
return WriteMapping.longMapping("datetime(3)", timestampWriteFunctionUsingSqlTimestamp(TIMESTAMP_MILLIS));
Copy link
Member

Choose a reason for hiding this comment

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

If I am reading correctly, this would only write TIMESTAMP(3) as datetime(3) and fallback to legacy write mapping for other types (which doesn't have a mapping for TIMESTAMP type at all so throwing an "Unsupported column type" error).

Let's change this branch to run for anything that is a TimestampType and try to see if we can write as timestamp(p) where p is the precision obtained from the type. See SqlServerClient for reference.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a relatively straightforward change. I was comparing to create table instead of insert, but that way makes more sense.

Copy link
Member Author

@jirassimok jirassimok Mar 5, 2021

Choose a reason for hiding this comment

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

On second thought, I think this way might be better, especially if we fix #6910 any time soon.

It doesn't really make sense for CTAS to allow more precisions than INSERT, so I think we should always write as DATETIME(3) until #6910.

That leaves us with the option to automatically convert all TIMESTAMPs to precision 3 before inserting on CTAS, but I think that rejecting them is a less surprising behavior, especially if we're soon going to change it to allow other precisions soon.

Copy link
Member

Choose a reason for hiding this comment

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

This is definitely correct change. @hashhar note that other timesamps with other precision are simply not supported here and cannot be created at all

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for catching this @jirassimok and @findepi . I missed that CTAS flow differs from INSERT.
I'll fix it in #6910 .

@findepi findepi changed the title Use timestamp precision 3 in CTAS in MySql Use timestamp precision 3 in CTAS in MySQL Mar 5, 2021
@jirassimok jirassimok force-pushed the mysql-ctas-timestamp branch from 0c69010 to 8f58db6 Compare March 5, 2021 15:33
/**
* Read {@code TIMESTAMP}s inserted by MySql as Trino {@code TIMESTAMP}s
*/
// TODO reuse these test cases in testTimestampFromTrino once we support timestamps with precisions other than 3 (https://github.com/trinodb/trino/issues/6910)
Copy link
Member

Choose a reason for hiding this comment

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

I don't think it will be reusable, unless MySQL supports picosecond precision

Copy link
Member Author

Choose a reason for hiding this comment

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

"Reuse" is the wrong word here.

Since we separated these tests into their own method, I think this comment is probably unnecessary. We'll need to add more tests when we support more precisions, which is all that this comment is saying now.

@@ -352,7 +352,7 @@ public WriteMapping toWriteMapping(ConnectorSession session, Type type)
}
if (TIMESTAMP_MILLIS.equals(type)) {
// TODO use `timestampWriteFunction` (https://github.com/trinodb/trino/issues/6910)
return WriteMapping.longMapping("datetime", timestampWriteFunctionUsingSqlTimestamp(TIMESTAMP_MILLIS));
return WriteMapping.longMapping("datetime(3)", timestampWriteFunctionUsingSqlTimestamp(TIMESTAMP_MILLIS));
Copy link
Member

Choose a reason for hiding this comment

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

This is definitely correct change. @hashhar note that other timesamps with other precision are simply not supported here and cannot be created at all

- Separate tests that insert timestamps with Trino from tests that
  insert from MySQL
- Move the Trino-insert tests after the MySQL-insert tests
- Rename the timestamp test methods to state how they insert data
@jirassimok jirassimok force-pushed the mysql-ctas-timestamp branch from 8f58db6 to 9a18806 Compare March 5, 2021 22:23
Copy link
Member

@hashhar hashhar left a comment

Choose a reason for hiding this comment

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

LGTM % leftover TODO comment.

@jirassimok jirassimok force-pushed the mysql-ctas-timestamp branch from 9a18806 to 2f2c19e Compare March 8, 2021 14:57
Copy link
Member

@hashhar hashhar left a comment

Choose a reason for hiding this comment

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

LGTM.

@findepi
Copy link
Member

findepi commented Mar 8, 2021

Do we have the same problem for MemSQL?

@findepi findepi merged commit 62c100c into trinodb:master Mar 8, 2021
@findepi findepi added this to the 354 milestone Mar 8, 2021
@findepi findepi mentioned this pull request Mar 8, 2021
10 tasks
@jirassimok
Copy link
Member Author

Do we have the same problem for MemSQL?

Yes; I'm looking into it.

@jirassimok
Copy link
Member Author

MemSQL only supports datetime/timestamp precisions 0 and 6, so this is either the same issue as #5450, or very closely related to it (in the same way #6910 relates to #5449).

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

Successfully merging this pull request may close these issues.

3 participants