-
Notifications
You must be signed in to change notification settings - Fork 94
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(c/driver): Date32 support #948
Changes from all commits
eefacad
be37055
4c64214
84b500f
b4f9b62
b585b83
12530a9
4f2e068
09b45e4
6c09ee9
adc8466
0d75469
15deeea
253452f
d303a8a
684e48e
6ff44f6
d4bf1bb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1037,6 +1037,10 @@ void StatementTest::TestSqlIngestNumericType(ArrowType type) { | |
// values. Likely a bug on our side, but for now, avoid them. | ||
values.push_back(static_cast<CType>(-1.5)); | ||
values.push_back(static_cast<CType>(1.5)); | ||
} else if (type == ArrowType::NANOARROW_TYPE_DATE32) { | ||
// Windows does not seem to support negative date values | ||
values.push_back(static_cast<CType>(0)); | ||
values.push_back(static_cast<CType>(42)); | ||
} else { | ||
values.push_back(std::numeric_limits<CType>::lowest()); | ||
values.push_back(std::numeric_limits<CType>::max()); | ||
|
@@ -1095,8 +1099,12 @@ void StatementTest::TestSqlIngestBinary() { | |
NANOARROW_TYPE_BINARY, {std::nullopt, "", "\x00\x01\x02\x04", "\xFE\xFF"})); | ||
} | ||
|
||
void StatementTest::TestSqlIngestDate32() { | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestNumericType<int32_t>(NANOARROW_TYPE_DATE32)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right now this tests the postgres implementation, but the SQLite implementation doesn't get tested since the roundtrip value is a string. For the timestamps we have separate test bodies and a function like The general problem is finding the right pattern to round trip tests for things where the input type doesn't match the output type There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about something like this? #787 What I envision there is a set of directories, one per vendor, where each has a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. More verbose, but then for drivers where there's overlap (e.g. Postgres in Java, Postgres in C++) we can also use them to assert that the behavior matches. The problem is checking in binaries; I was thinking we could borrow the arrow-testing submodule to do that to avoid cluttering the main repo. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this makes sense. Before I go too deep - when looking at this I figured we would have to vendor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, and to be clear, I think there's no need to go that far in this PR - just something for later evaluation |
||
} | ||
|
||
template <enum ArrowTimeUnit TU> | ||
void StatementTest::TestSqlIngestTemporalType(const char* timezone) { | ||
void StatementTest::TestSqlIngestTimestampType(const char* timezone) { | ||
if (!quirks()->supports_bulk_ingest()) { | ||
GTEST_SKIP(); | ||
} | ||
|
@@ -1155,7 +1163,7 @@ void StatementTest::TestSqlIngestTemporalType(const char* timezone) { | |
ASSERT_EQ(values.size(), reader.array->length); | ||
ASSERT_EQ(1, reader.array->n_children); | ||
|
||
ValidateIngestedTemporalData(reader.array_view->children[0], TU, timezone); | ||
ValidateIngestedTimestampData(reader.array_view->children[0], TU, timezone); | ||
|
||
ASSERT_NO_FATAL_FAILURE(reader.Next()); | ||
ASSERT_EQ(nullptr, reader.array->release); | ||
|
@@ -1164,33 +1172,34 @@ void StatementTest::TestSqlIngestTemporalType(const char* timezone) { | |
ASSERT_THAT(AdbcStatementRelease(&statement, &error), IsOkStatus(&error)); | ||
} | ||
|
||
void StatementTest::ValidateIngestedTemporalData(struct ArrowArrayView* values, | ||
enum ArrowTimeUnit unit, | ||
const char* timezone) { | ||
FAIL() << "ValidateIngestedTemporalData is not implemented in the base class"; | ||
void StatementTest::ValidateIngestedTimestampData(struct ArrowArrayView* values, | ||
enum ArrowTimeUnit unit, | ||
const char* timezone) { | ||
FAIL() << "ValidateIngestedTimestampData is not implemented in the base class"; | ||
} | ||
|
||
void StatementTest::TestSqlIngestTimestamp() { | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_SECOND>(nullptr)); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_MILLI>(nullptr)); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_MICRO>(nullptr)); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_NANO>(nullptr)); | ||
ASSERT_NO_FATAL_FAILURE( | ||
TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_SECOND>(nullptr)); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_MILLI>(nullptr)); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_MICRO>(nullptr)); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_NANO>(nullptr)); | ||
} | ||
|
||
void StatementTest::TestSqlIngestTimestampTz() { | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_SECOND>("UTC")); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_MILLI>("UTC")); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_MICRO>("UTC")); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_NANO>("UTC")); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_SECOND>("UTC")); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_MILLI>("UTC")); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_MICRO>("UTC")); | ||
ASSERT_NO_FATAL_FAILURE(TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_NANO>("UTC")); | ||
|
||
ASSERT_NO_FATAL_FAILURE( | ||
TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_SECOND>("America/Los_Angeles")); | ||
TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_SECOND>("America/Los_Angeles")); | ||
ASSERT_NO_FATAL_FAILURE( | ||
TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_MILLI>("America/Los_Angeles")); | ||
TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_MILLI>("America/Los_Angeles")); | ||
ASSERT_NO_FATAL_FAILURE( | ||
TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_MICRO>("America/Los_Angeles")); | ||
TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_MICRO>("America/Los_Angeles")); | ||
ASSERT_NO_FATAL_FAILURE( | ||
TestSqlIngestTemporalType<NANOARROW_TIME_UNIT_NANO>("America/Los_Angeles")); | ||
TestSqlIngestTimestampType<NANOARROW_TIME_UNIT_NANO>("America/Los_Angeles")); | ||
} | ||
|
||
void StatementTest::TestSqlIngestInterval() { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having to use 0 as a minimum value here is unfortunate. I couldn't find any real documentation on gmtime_s limitations in Windows, except that the upper limit on 64 bit systems is through the year 3000
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/gmtime-s-gmtime32-s-gmtime64-s?view=msvc-170
Guessing it may also just not support negative dates in a way that is undocumented? Unfortunately I do not have a windows machine available to test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh.
I wonder if we shouldn't also consider vendoring a library for that down the line...that would be easier if/when we also consolidate the driver codebases