You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@beam.apache.org by "Eliaaazzz (via GitHub)" <gi...@apache.org> on 2026/05/15 14:21:18 UTC
[PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Eliaaazzz opened a new pull request, #38510:
URL: https://github.com/apache/beam/pull/38510
ClickHouseIO's `TableSchema` and column-type parser only recognized `DateTime` (second precision), so pipelines emitting sub-second timestamps (log/event ingestion, financial data) could not write to ClickHouse tables declared with `DateTime64(precision[, 'timezone'])` columns.
This change adds first-class `DateTime64` support to `ClickHouseIO`:
* **Schema model** — new `TypeName.DATETIME64`; `ColumnType` carries `precision` (0–9, validated) and an optional `timezone`, with a `ColumnType.dateTime64(precision[, timezone])` factory.
* **Parser** — JavaCC grammar rule for `DateTime64(<precision>[, '<timezone>'])`, also reachable through `Nullable(...)` and `Array(...)` via the existing `primitive()` rule.
* **Beam field-type mapping** — picks the narrowest logical type that round-trips the requested precision:
* `precision ≤ 3` → Joda `DATETIME` (preserves existing pipelines).
* `precision 4–6` → `SqlTypes.TIMESTAMP` (`MicrosInstant`).
* `precision ≥ 7` → `NanosInstant`, the only built-in logical type that preserves full nanosecond precision through a `Row`; `MicrosInstant` rejects non-micro-aligned nanos.
* **Writer** — serializes `DateTime64` as a little-endian `Int64` of `epoch_seconds * 10^precision + sub_second_units`, accepting both Joda `ReadableInstant` and `java.time.Instant`. Uses `Math.floorDiv` / `Math.floorMod` so negative timestamps match ClickHouse's encoding, and `Math.multiplyExact` / `Math.addExact` for overflow safety.
Tests:
* `TableSchemaTest` — parser cases for `DateTime64(3)`, `DateTime64(6, 'UTC')`, `DateTime64(9)`, `Nullable(DateTime64(...))`, `Array(DateTime64(...))`; schema-mapping tests for the millis, micros and nanos buckets; precision-range validation.
* `ClickHouseWriterTest` — encoder unit tests covering Joda and `java.time.Instant` inputs, precision 0/3/6/7/9, negative timestamps and the precision-7 100 ns truncation path.
* `ClickHouseIOIT` — round-trip integration tests against the ClickHouse test container for precisions 3/6/9 (the 9-precision case uses non-micro-aligned nanos) and `Nullable(DateTime64(6))`.
fixes #38466
------------------------
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:
- [x] Mention the appropriate issue in your description (for example: \`addresses #123\`), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment \`fixes #<ISSUE NUMBER>\` instead.
- [x] Update \`CHANGES.md\` with noteworthy changes.
- [ ] If this contribution is large, please file an Apache [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
See the [Contributor Guide](https://beam.apache.org/contribute) for more tips on [how to make review process smoother](https://github.com/apache/beam/blob/master/CONTRIBUTING.md#make-the-reviewers-job-easier).
To check the build health, please visit [https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md](https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md)
GitHub Actions Tests Status (on master branch)
------------------------------------------------------------------------------------------------
[](https://github.com/apache/beam/actions?query=workflow%3A%22Build+python+source+distribution+and+wheels%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Python+Tests%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Java+Tests%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Go+tests%22+branch%3Amaster+event%3Aschedule)
See [CI.md](https://github.com/apache/beam/blob/master/CI.md) for more information about GitHub Actions CI or the [workflows README](https://github.com/apache/beam/blob/master/.github/workflows/README.md) to see a list of phrases to trigger workflows.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "Abacn (via GitHub)" <gi...@apache.org>.
Abacn commented on PR #38510:
URL: https://github.com/apache/beam/pull/38510#issuecomment-4465018623
Thanks, this looks pretty complete. R: @BentsiLeviav (ClickHouseIO owner) could you please take a look?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #38510:
URL: https://github.com/apache/beam/pull/38510#issuecomment-4465022303
Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control. If you'd like to restart, comment `assign set of reviewers`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "Eliaaazzz (via GitHub)" <gi...@apache.org>.
Eliaaazzz commented on PR #38510:
URL: https://github.com/apache/beam/pull/38510#issuecomment-4701635226
Thanks for the review. I addressed all the comments:
- Removed the unused timezone field. The parser still accepts the timezone argument but ignores it.
- A bare DateTime64 now parses and defaults to precision 3.
- A bad precision and a typo now both funnel through the same failed to parse error.
- Moved the magic numbers in the IT and unit tests into named constants.
- Added a nullable DateTime64(9) integration test that writes both a value and a null.
- Added overflow and null input tests in the writer test.
- Reused a single NanosInstant constant and null-check the precision before unboxing.
Let me know if anything else needs a change.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "gemini-code-assist[bot] (via GitHub)" <gi...@apache.org>.
gemini-code-assist[bot] commented on PR #38510:
URL: https://github.com/apache/beam/pull/38510#issuecomment-4460576807
## Summary of Changes
Hello, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces support for ClickHouse's DateTime64 data type, allowing users to write timestamps with sub-second precision (up to nanoseconds) to ClickHouse tables. The changes include updates to the schema model, parser, and writer to accommodate the precision and timezone requirements of DateTime64, while maintaining backward compatibility for existing pipelines using standard DateTime.
### Highlights
* **DateTime64 Support**: Added first-class support for ClickHouse DateTime64 columns, enabling sub-second timestamp precision in pipelines.
* **Schema Mapping**: Implemented dynamic Beam field-type mapping based on precision: Joda DATETIME for <=3, SqlTypes.TIMESTAMP for 4-6, and NanosInstant for >=7.
* **Writer Logic**: Updated the ClickHouse writer to handle serialization of DateTime64 as a 64-bit integer, ensuring correct handling of negative timestamps and overflow safety.
* **Parser Updates**: Extended the JavaCC grammar to support parsing DateTime64(precision[, 'timezone']) definitions.
<details>
<summary><b>New Features</b></summary>
🧠 You can now enable **Memory** (public preview) to help **Gemini Code Assist** learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. **Click [here](https://codeassist.google/code-review/login) to enable Memory in your admin console.**
</details>
<details>
<summary><b>Using Gemini Code Assist</b></summary>
<br>
The full guide for Gemini Code Assist can be found on our [documentation page](https://developers.google.com/gemini-code-assist/docs/review-github-code), here are some quick tips.
<b>Invoking Gemini</b>
You can request assistance from Gemini at any point by creating a comment using either `/gemini <command>` or `@gemini-code-assist <command>`. Below is a summary of the supported commands on the current page.
Feature | Command | Description
--- | --- | ---
Code Review | `/gemini review` | Performs a code review for the current pull request in its current state.
Pull Request Summary | `/gemini summary` | Provides a summary of the current pull request in its current state.
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help | `/gemini help` | Displays a list of available commands.
<b>Customization</b>
To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a `.gemini/` folder in the base of the repository. Detailed instructions can be found [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github).
<b>Limitations & Feedback</b>
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up [here](https://google.qualtrics.com/jfe/form/SV_2cyuGuTWsEw84yG).
</details>
[^1]: Review the [Privacy Notices](https://policies.google.com/privacy), [Generative AI Prohibited Use Policy](https://policies.google.com/terms/generative-ai/use-policy), [Terms of Service](https://policies.google.com/terms), and learn how to configure Gemini Code Assist in GitHub [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github). Gemini can make mistakes, so double check it and [use code with caution](https://support.google.com/legal/answer/13505487).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "gemini-code-assist[bot] (via GitHub)" <gi...@apache.org>.
gemini-code-assist[bot] commented on code in PR #38510:
URL: https://github.com/apache/beam/pull/38510#discussion_r3248847275
##########
sdks/java/io/clickhouse/src/main/java/org/apache/beam/sdk/io/clickhouse/TableSchema.java:
##########
@@ -76,6 +78,22 @@ public static Schema.FieldType getEquivalentFieldType(ColumnType columnType) {
case DATETIME:
return Schema.FieldType.DATETIME;
+ case DATETIME64:
+ // Pick the narrowest Beam logical type that still round-trips the requested precision:
+ // ≤ 3 (milliseconds) → Joda DATETIME, keeping existing pipelines unchanged.
+ // 4–6 (down to microseconds) → SqlTypes.TIMESTAMP (MicrosInstant) — interoperable
+ // with BigQueryIO, Avro and Beam SQL.
+ // ≥ 7 (sub-microsecond) → NanosInstant, the only built-in type that preserves
+ // full nanosecond precision through Row construction.
+ int p = columnType.precision();
+ if (p <= 3) {
+ return Schema.FieldType.DATETIME;
+ } else if (p <= 6) {
+ return Schema.FieldType.logicalType(SqlTypes.TIMESTAMP);
+ } else {
+ return Schema.FieldType.logicalType(new NanosInstant());
Review Comment:
For better performance and consistency with other logical types (like `SqlTypes.TIMESTAMP`), consider defining a private constant for `NanosInstant` instead of instantiating it every time `getEquivalentFieldType` is called for a `DATETIME64` column with precision ≥ 7.
```suggestion
return Schema.FieldType.logicalType(NANOS_INSTANT);
```
##########
sdks/java/io/clickhouse/src/main/java/org/apache/beam/sdk/io/clickhouse/ClickHouseWriter.java:
##########
@@ -138,6 +171,10 @@ static void writeValue(ClickHouseOutputStream stream, ColumnType columnType, Obj
BinaryStreamUtils.writeUnsignedInt32(stream, epochSeconds);
break;
+ case DATETIME64:
+ BinaryStreamUtils.writeInt64(stream, encodeDateTime64(value, columnType.precision()));
Review Comment:
The `precision()` method on `ColumnType` is marked as `@Nullable`. While the factory and parser ensure it is set for `DATETIME64`, unboxing it here to an `int` for the `encodeDateTime64` call could theoretically throw a `NullPointerException` if a `ColumnType` was manually constructed via the builder without a precision. Consider adding a null check or using `Objects.requireNonNull` for robustness.
```suggestion
BinaryStreamUtils.writeInt64(stream, encodeDateTime64(value, java.util.Objects.requireNonNull(columnType.precision())));
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "Abacn (via GitHub)" <gi...@apache.org>.
Abacn merged PR #38510:
URL: https://github.com/apache/beam/pull/38510
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #38510:
URL: https://github.com/apache/beam/pull/38510#issuecomment-4463508098
Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment `assign set of reviewers`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "BentsiLeviav (via GitHub)" <gi...@apache.org>.
BentsiLeviav commented on PR #38510:
URL: https://github.com/apache/beam/pull/38510#issuecomment-4706849692
@Eliaaazzz Thanks!
One last thing - at the top of `ClickHouseIO.java` there's a documentation table that lists every ClickHouse type and what Beam type it maps to. Can you add the Datetime64? https://github.com/apache/beam/blob/b3a62ee97c7ce436fc70dfc7d13f94dd97038b1b/sdks/java/io/clickhouse/src/main/java/org/apache/beam/sdk/io/clickhouse/ClickHouseIO.java#L124
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "Eliaaazzz (via GitHub)" <gi...@apache.org>.
Eliaaazzz commented on PR #38510:
URL: https://github.com/apache/beam/pull/38510#issuecomment-4708580214
> LGTM. Thanks for your contribution!
No worries! Thanks for your review!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ClickHouseIO: Add DateTime64 support for sub-second timestamp precision [beam]
Posted by "BentsiLeviav (via GitHub)" <gi...@apache.org>.
BentsiLeviav commented on code in PR #38510:
URL: https://github.com/apache/beam/pull/38510#discussion_r3369680648
##########
sdks/java/io/clickhouse/src/main/java/org/apache/beam/sdk/io/clickhouse/TableSchema.java:
##########
@@ -238,6 +257,14 @@ public abstract static class ColumnType implements Serializable {
public abstract @Nullable Map<String, ColumnType> tupleTypes();
+ /** Sub-second precision (0–9) of {@code DateTime64}. {@code null} for other types. */
+ public abstract @Nullable Integer precision();
+
+ /**
+ * Optional timezone of {@code DateTime64}; semantically display-only. {@code null} otherwise.
+ */
+ public abstract @Nullable String timezone();
Review Comment:
Is preserving it adding value, or is it a dead state? I see no usage for that
##########
sdks/java/io/clickhouse/src/test/java/org/apache/beam/sdk/io/clickhouse/ClickHouseIOIT.java:
##########
@@ -480,6 +482,79 @@ public void testPojo() throws Exception {
assertEquals(12L, sum1);
}
+ @Test
+ public void testDateTime64Millis() throws Exception {
+ Schema schema = Schema.of(Schema.Field.of("ts", FieldType.DATETIME));
+ DateTime ts = new DateTime(2026, 5, 15, 12, 34, 56, 789, DateTimeZone.UTC);
+ Row row = Row.withSchema(schema).addValue(ts).build();
+
+ executeSql("CREATE TABLE test_datetime64_ms (ts DateTime64(3, 'UTC')) ENGINE=Log");
+
+ pipeline.apply(Create.of(row).withRowSchema(schema)).apply(write("test_datetime64_ms"));
+ pipeline.run().waitUntilFinish();
+
+ // toUnixTimestamp64Milli returns the underlying tick count, which is the most stable thing to
+ // assert across CH versions (string formatting may include trailing zeros depending on
+ // version).
+ long ticks = executeQueryAsLong("SELECT toUnixTimestamp64Milli(ts) FROM test_datetime64_ms");
+ assertEquals(ts.getMillis(), ticks);
+ }
+
+ @Test
+ public void testDateTime64Micros() throws Exception {
+ Schema schema = Schema.of(Schema.Field.of("ts", FieldType.logicalType(SqlTypes.TIMESTAMP)));
+ // 2026-05-15T12:34:56.789012Z — exactly micros, so MicrosInstant accepts it.
+ java.time.Instant ts = java.time.Instant.ofEpochSecond(1_778_071_696L, 789_012_000L);
+ Row row = Row.withSchema(schema).addValue(ts).build();
+
+ executeSql("CREATE TABLE test_datetime64_us (ts DateTime64(6)) ENGINE=Log");
+
+ pipeline.apply(Create.of(row).withRowSchema(schema)).apply(write("test_datetime64_us"));
+ pipeline.run().waitUntilFinish();
+
+ long ticks = executeQueryAsLong("SELECT toUnixTimestamp64Micro(ts) FROM test_datetime64_us");
+ assertEquals(1_778_071_696L * 1_000_000L + 789_012L, ticks);
+ }
+
+ @Test
+ public void testDateTime64Nanos() throws Exception {
+ // DateTime64(9) must preserve full nanosecond precision. Use NanosInstant directly
+ // because SqlTypes.TIMESTAMP (MicrosInstant) rejects non-micro-aligned nanos like the
+ // trailing 345 below.
+ Schema schema = Schema.of(Schema.Field.of("ts", FieldType.logicalType(new NanosInstant())));
+ java.time.Instant ts = java.time.Instant.ofEpochSecond(1_778_071_696L, 789_012_345L);
+ Row row = Row.withSchema(schema).addValue(ts).build();
+
+ executeSql("CREATE TABLE test_datetime64_ns (ts DateTime64(9)) ENGINE=Log");
+
+ pipeline.apply(Create.of(row).withRowSchema(schema)).apply(write("test_datetime64_ns"));
+ pipeline.run().waitUntilFinish();
+
+ long ticks = executeQueryAsLong("SELECT toUnixTimestamp64Nano(ts) FROM test_datetime64_ns");
+ assertEquals(1_778_071_696L * 1_000_000_000L + 789_012_345L, ticks);
+ }
+
+ @Test
+ public void testNullableDateTime64() throws Exception {
Review Comment:
Nullable and non-nullable take different code paths in the writer - can we also have a nullable assertion with a nanos tedt?
##########
sdks/java/io/clickhouse/src/test/java/org/apache/beam/sdk/io/clickhouse/ClickHouseWriterTest.java:
##########
Review Comment:
Great coverage. Can we also add:
* Overflow test - `Math.multiplyExact` will throw `ArithmeticException` for a `DateTime64(9)` timestamp past ~year 2262.
* Null input test - The reject test covers a wrong type, but not null ( The method has a specific `value == null ? "null" : …` branch in its error message that's currently unexercised.)
##########
sdks/java/io/clickhouse/src/main/javacc/ColumnTypeParser.jj:
##########
@@ -214,10 +216,28 @@ private ColumnType primitive() :
(<FIXEDSTRING> <LPAREN> ( size = integer() ) <RPAREN>) {
return ColumnType.fixedString(Integer.valueOf(size));
}
+ |
+ (ct = dateTime64()) { return ct; }
)
}
+private ColumnType dateTime64() :
+{
+ String precision;
+ String timezone = null;
+}
+{
+ (
+ <DATETIME64> <LPAREN> ( precision = integer() )
Review Comment:
Bare DateTime64 (no precision) won't parse. The `<LPAREN> integer() <RPAREN>` is mandatory, but ClickHouse accepts a bare DateTime64 that defaults to precision 3. To be fully covered, can we make the whole argument list optional and default to 3?
##########
sdks/java/io/clickhouse/src/test/java/org/apache/beam/sdk/io/clickhouse/ClickHouseIOIT.java:
##########
@@ -480,6 +482,79 @@ public void testPojo() throws Exception {
assertEquals(12L, sum1);
}
+ @Test
+ public void testDateTime64Millis() throws Exception {
+ Schema schema = Schema.of(Schema.Field.of("ts", FieldType.DATETIME));
+ DateTime ts = new DateTime(2026, 5, 15, 12, 34, 56, 789, DateTimeZone.UTC);
+ Row row = Row.withSchema(schema).addValue(ts).build();
+
+ executeSql("CREATE TABLE test_datetime64_ms (ts DateTime64(3, 'UTC')) ENGINE=Log");
+
+ pipeline.apply(Create.of(row).withRowSchema(schema)).apply(write("test_datetime64_ms"));
+ pipeline.run().waitUntilFinish();
+
+ // toUnixTimestamp64Milli returns the underlying tick count, which is the most stable thing to
+ // assert across CH versions (string formatting may include trailing zeros depending on
+ // version).
+ long ticks = executeQueryAsLong("SELECT toUnixTimestamp64Milli(ts) FROM test_datetime64_ms");
+ assertEquals(ts.getMillis(), ticks);
+ }
+
+ @Test
+ public void testDateTime64Micros() throws Exception {
+ Schema schema = Schema.of(Schema.Field.of("ts", FieldType.logicalType(SqlTypes.TIMESTAMP)));
+ // 2026-05-15T12:34:56.789012Z — exactly micros, so MicrosInstant accepts it.
+ java.time.Instant ts = java.time.Instant.ofEpochSecond(1_778_071_696L, 789_012_000L);
+ Row row = Row.withSchema(schema).addValue(ts).build();
+
+ executeSql("CREATE TABLE test_datetime64_us (ts DateTime64(6)) ENGINE=Log");
+
+ pipeline.apply(Create.of(row).withRowSchema(schema)).apply(write("test_datetime64_us"));
+ pipeline.run().waitUntilFinish();
+
+ long ticks = executeQueryAsLong("SELECT toUnixTimestamp64Micro(ts) FROM test_datetime64_us");
+ assertEquals(1_778_071_696L * 1_000_000L + 789_012L, ticks);
Review Comment:
styling comment - can we move those magic numbers (also in unit tests) to a meaningful consts? will be easier to understand
##########
sdks/java/io/clickhouse/src/main/javacc/ColumnTypeParser.jj:
##########
@@ -214,10 +216,28 @@ private ColumnType primitive() :
(<FIXEDSTRING> <LPAREN> ( size = integer() ) <RPAREN>) {
return ColumnType.fixedString(Integer.valueOf(size));
}
+ |
+ (ct = dateTime64()) { return ct; }
)
}
+private ColumnType dateTime64() :
+{
+ String precision;
+ String timezone = null;
+}
+{
+ (
+ <DATETIME64> <LPAREN> ( precision = integer() )
+ ( <COMMA> ( timezone = string() ) )?
+ <RPAREN>
+ )
+ {
+ return ColumnType.dateTime64(Integer.parseInt(precision), timezone);
Review Comment:
Minor comment - a typo like `DateTime64(abc)` will result in `IllegalArgumentException: "failed to parse"`, while a bad precision like `DateTime64(-1)` will result in a different exception with a different message, from a different layer. Should we catch and rethrow so all bad input funnels through the same `failed to parse` error?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org