Fix client-v1 DateTime64 test failing on ClickHouse 26.8 - #3117
Open
polyglotAI-bot wants to merge 1 commit into
Open
Fix client-v1 DateTime64 test failing on ClickHouse 26.8#3117polyglotAI-bot wants to merge 1 commit into
polyglotAI-bot wants to merge 1 commit into
Conversation
testReadWriteSimpleTypes wrote an unquoted number into the DateTime64(3) column. From 26.8 such a number is a Unix timestamp in seconds instead of the raw scaled value (default of input_format_read_datetime_number_as_raw_value moved from 1 to 0), so the row read back was 1970-01-01 00:00:01 instead of 1970-01-01 00:00:00.001. Write a quoted date-time literal for DateTime64, as the test already does for FixedString and UUID, so the value means the same on every server version. Fixes: #3114
|
Client V2 CoverageCoverage Report
Class Coverage
|
JDBC V2 CoverageCoverage Report
Class Coverage
|
JDBC V1 CoverageCoverage Report
Class Coverage
|
Client V1 CoverageCoverage Report
Class Coverage
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes #3114.
ClientIntegrationTest.testReadWriteSimpleTypesbuilds its insert from the plain literals0,-1and1for every type insimpleTypeProvider. For theDateTime64(3)row that literal is unquoted, and its meaning changed on the server: from 26.8 an unquoted number written to aDateTime64column in theValues/QuotedandJSONpaths is a Unix timestamp in seconds, consistent withCASTandtoDateTime64, instead of the raw scaled value.system.settings_changesrecords the change - the default ofinput_format_read_datetime_number_as_raw_valuemoved from1to0in 26.8. Soinsert into ... values(1)stores1970-01-01 00:00:01, while the test expects1970-01-01 00:00:00.001.Verified directly against two servers, same table and same statement:
insert into t(d DateTime64(3)) values(1)toUnixTimestamp64Milli(d)1970-01-01 00:00:00.00111970-01-01 00:00:01.0001000The read path is correct - the client returns exactly what the server stored - so this is a test fixture that encodes pre-26.8 server semantics, not a client defect.
The fix writes a quoted date-time literal for
DateTime64, the same way the test already does forFixedStringandUUID. The written value then means the same on every server version, the expected values in the data provider are unchanged, and the sub-second round-trip (.001/.999) stays covered on current servers - which a version-dependent expectation of whole seconds would have lost.Impact on the v2 stack (asked for in the issue): none.
client-v2writes date-time values inRowBinary, andjdbc-v2renders a bound value either as a quoted literal (DataTypeUtils.DATE_TIME_WITH_OPTIONAL_NANOS) or throughfromUnixTimestamp64Nano(...);clickhouse-dataClickHouseDateTimeValue.toSqlExpression()also quotes. No client path sends a bare number for aDateTime64column, and everyDateTime64insert in theclient-v2,jdbc-v2,clickhouse-jdbcandclickhouse-r2dbctests uses a quoted literal or an explicit::DateTime64cast. Applications that write an unquoted number themselves are affected by the server change and can restore the old reading withinput_format_read_datetime_number_as_raw_value=1orcompatibility='26.7'.Changes
clickhouse-client/src/test/java/com/clickhouse/client/ClientIntegrationTest.java: quote the inserted literal forDateTime64intestReadWriteSimpleTypes, next to the existingFixedStringandUUIDbranches.CHANGELOG.md: entry under0.11.0-rc1/ Bug Fixes describing the server change and the fix.Test
testReadWriteSimpleTypesitself is the regression test - theDateTime64(3)row fails onmainagainst 26.8 and passes with the change, with the same expected values on both server versions.mvn -pl clickhouse-http-client -DskipUTs=true -Dit.test=ClickHouseHttpClientTest verifyagainst 26.8.1.2041: fails onmain(expected [1970-01-01 00:00:00.001] but found [1970-01-01 00:00:01]), passes with the change.testProxyConnection, and the two SSL client-auth tests whose certificate CN does not match the container host); they fail the same way before and after the change.No existing test was weakened, and no product code changed.
Pre-PR validation gate
mainon 26.8, every run)AGENTS.md(scope, test conventions, CHANGELOG entry)