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

Ongoing fixes #356

Merged
merged 21 commits into from
Aug 3, 2021
Merged

Ongoing fixes #356

merged 21 commits into from
Aug 3, 2021

Conversation

@traceon traceon marked this pull request as ready for review July 22, 2021 00:19
Some refactoring
Add Date/DateTime/DateTime64 testing
@traceon traceon requested a review from Enmk July 24, 2021 20:48
Copy link
Collaborator

@Enmk Enmk left a comment

Choose a reason for hiding this comment

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

There are some minor questions, but overall looks good.

void Connection::verifyConnection() {
LOG("Verifying connection and credentials...");
auto & statement = allocateChild<Statement>();
statement.executeQuery("SELECT 1");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can executeQuery() throw an exception? If yes, will the statement be successfully deallocated later?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, I should have added a proper cleanup there. Will fix.


const auto tmp_type_without_parameters_id = convertUnparametrizedTypeNameToTypeId(tmp_type_name_without_parameters);

if (huge_int_as_string && tmp_type_without_parameters_id == DataSourceTypeId::UInt64) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

What about other wide types, like Int128, UInt128, Decimal128 and wider?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Int128/UInt128 are not supported in the driver yet. Decimal128 is extracted as string or double anyway (there is no standard Decimal C type), so no need to alter the way it is reported to the ODBC clients.

void RowBinaryWithNamesAndTypesResultSet::readValue(DataSourceType<DataSourceTypeId::Date> & dest, ColumnInfo & column_info) {
WireTypeDateAsInt dest_raw;
WireTypeDateAsInt dest_raw(column_info.timezone);
Copy link
Collaborator

@Enmk Enmk Aug 2, 2021

Choose a reason for hiding this comment

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, but the timezone (of the data/server) might be used when it is converted (read by the user) to some DateTime structures.

@@ -152,14 +153,24 @@ void RowBinaryWithNamesAndTypesResultSet::readValue(WireTypeDateTimeAsInt & dest
readPOD(dest.value);
}

void RowBinaryWithNamesAndTypesResultSet::readValue(WireTypeDateTime64AsInt & dest, ColumnInfo & column_info) {
readPOD(dest.value);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Did you forget to use\convert value according to a timezone?

Copy link
Collaborator Author

@traceon traceon Aug 2, 2021

Choose a reason for hiding this comment

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


class DateTime
: public ClientTestWithParamBase<
std::tuple<
Copy link
Collaborator

Choose a reason for hiding this comment

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

IMO it is better to use named struct here, it is easier to read and reason about.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Changed.

@traceon
Copy link
Collaborator Author

traceon commented Aug 3, 2021

GCC builds in macOS are failing due to nanodbc - a fix for that was proposed in their repo, once (and if) it is merged and submodule here is bumped, these failures will be gone. For now, it is fairly safe to merge with those builds failing.

@traceon traceon merged commit 35394e5 into ClickHouse:master Aug 3, 2021
@traceon traceon deleted the ongoing-fixes branch August 4, 2021 12:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment