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

feat: timestamp support - casting, comparisons and serde #6806

Merged
merged 5 commits into from
Jan 7, 2021

Conversation

jzaralim
Copy link
Contributor

@jzaralim jzaralim commented Dec 19, 2020

Description

First pass at adding timestamp type support (#4148). This PR includes casting between strings and timestamps, comparisons and JSON/Avro/Delimited serde.

It looks like a lot of files, but most are tests or changes that involve adding timestamp to a list of types. All the other files can be broken down as follows:

Parsing

  • SqlBase.g4: removed unused references to TIME(STAMP)_WITH_TIME_ZONE
  • TimestampLiteral
  • PartialStringToTimestampParser: reusing this helper for parsing strings to timestamp types
  • SqlTimestamps: helper functions to convert between strings and timestamps
  • TimestampType
  • ApiJsonMapper

Casting

  • DefaultSqlValueCoercer and CastEvaluator: logic for string/timestamp casting
  • SqlBaseType
  • GenericExpressionResolver: warning for casting incorrectly formed strings to timestamps

Comparisons

  • SqlToJavaVisitor: enables timestamp comparisons and wraps strings being compared to timestamps with a timestamp parser
  • ComparisonUtil

Serde

  • ConnectDataTranslator
  • KsqlDelimitedDeserializer and KsqlDelimitedSerializer
  • JsonSerdeUtils.java and KsqlJsonDeserializer

Not included in this PR:

  • Documentation (this will be in a separate PR)
  • UDF/UDAF support
  • Arithmetic functions
  • Protobuf support - KSQL can't create a new Protobuf topic unless google.protobuf.Timestamp is registered in Schema Registry.
  • Integration testing with Connect

Testing done

QTT and unit tests

Reviewer checklist

  • Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
  • Ensure relevant issues are linked (description should include text like "Fixes #")

@jzaralim jzaralim requested a review from a team as a code owner December 19, 2020 01:30
@jzaralim jzaralim changed the title Timestamp support - casting, comparisons and serde (feat) timestamp support - casting, comparisons and serde Dec 19, 2020
@jzaralim jzaralim changed the title (feat) timestamp support - casting, comparisons and serde feat: timestamp support - casting, comparisons and serde Dec 19, 2020
design-proposals/klip-43-timestamp-data-type-support.md Outdated Show resolved Hide resolved
@@ -62,13 +63,16 @@
private static final Schema CONNECT_BIGINT_SCHEMA = SchemaBuilder.int64().optional().build();
private static final Schema CONNECT_DOUBLE_SCHEMA = SchemaBuilder.float64().optional().build();
private static final Schema CONNECT_STRING_SCHEMA = SchemaBuilder.string().optional().build();
private static final Schema CONNECT_TIMESTAMP_SCHEMA =
SchemaBuilder.int64().name("org.apache.kafka.connect.data.Timestamp").version(1).optional().build();
Copy link
Member

Choose a reason for hiding this comment

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

What is version 1?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a part of the schema from the Timestamp class. This ended up being replaced by the builder from the Timestamp class though.

+ "Partials are also supported, for example \"2020-05-26\"";

private static final StringToTimestampParser PARSER =
new StringToTimestampParser(KsqlConstants.DATE_TIME_PATTERN);

public Timestamp parseToTimestamp(final String text) {
return new Timestamp(parse(text));
Copy link
Member

Choose a reason for hiding this comment

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

parse is gonna parse strings with timezones if the string contains +0200 for instance. Isn't this going to cause an issue?

Comment on lines +128 to +132
final Long longVal = Long.valueOf(spec.toString());
if (Timestamp.LOGICAL_NAME.equals(schema.name())) {
return Timestamp.toLogical(schema, (Long) spec);
return new java.sql.Timestamp(longVal);
}
return Long.valueOf(spec.toString());
return longVal;
Copy link
Member

Choose a reason for hiding this comment

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

Does it need changes in connectToSpec?

I see this code in that method:

case INT64:
          if (Timestamp.LOGICAL_NAME.equals(schema.name())) {
            return Timestamp.fromLogical(schema, (Date) data);
          }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

connectToSpec is used for checking the values in streams in functional tests. These values are verified against values in a json file and since json files cannot store timestamp objects, comparing the millis is the only way to check timestamp values.

Copy link
Member

@spena spena left a comment

Choose a reason for hiding this comment

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

Thanks @jzaralim. The code looks good to me. I'll run some tests on it once is merged and the rest of the changes is implemented.

@jzaralim jzaralim merged commit a27df46 into confluentinc:master Jan 7, 2021
@jzaralim jzaralim deleted the timestamp-impl branch February 3, 2021 20:50
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.

2 participants