fix: read_gbq supports extreme DATETIME values such as 0001-01-01 00:00:00#444
fix: read_gbq supports extreme DATETIME values such as 0001-01-01 00:00:00#444tswast merged 40 commits intogoogleapis:mainfrom
read_gbq supports extreme DATETIME values such as 0001-01-01 00:00:00#444Conversation
deps: require google-cloud-bigquery 1.26.1 or later
This reverts commit 2a76982.
|
I think we need to remove the python-bigquery-pandas/pandas_gbq/gbq.py Line 583 in e13abaf |
ci/requirements-3.7-0.24.2.conda
Outdated
| flake8 | ||
| numpy==1.16.6 | ||
| google-cloud-bigquery==1.11.1 | ||
| google-cloud-bigquery==1.26.1 |
There was a problem hiding this comment.
Needed for date_as_object parameter
| "DATE": "datetime64[ns]", | ||
| "DATETIME": "datetime64[ns]", | ||
| "FLOAT": np.dtype(float), | ||
| "GEOMETRY": "object", |
There was a problem hiding this comment.
I'm not sure how the changes here to non-datetime-related mappings relates to this PR.
If these changes are intentional, then the comment above seems to require a corresponding update to docs/reading.rst.
There was a problem hiding this comment.
object types were removed because it's the default anyway.
| "pyarrow >=3.0.0, <7.0dev", | ||
| "pydata-google-auth", | ||
| "google-api-core >=1.14.0", | ||
| "google-api-core >=1.21.0", |
There was a problem hiding this comment.
Seems unrelated, and unmotivated by anything in the changelog for that release.
There was a problem hiding this comment.
Correct. Needed to update due to updating the minimum google-cloud-bigquery, though.
We do use google-api-core directly, so I think it makes sense to include here still.
| google-api-core==1.14.0 | ||
| google-auth==1.4.1 | ||
| google-api-core==1.21.0 | ||
| google-auth==1.18.0 |
There was a problem hiding this comment.
Doesn't match the minimum constraint in setup.py.
There was a problem hiding this comment.
Updated setup.py. Needed this version due to updated google-api-core (via google-cloud-bigquery)
shollyman
left a comment
There was a problem hiding this comment.
LGTM, though all this version checking feels mildly terrifying.
|
|
||
| for field in schema_fields: | ||
| column = str(field["name"]) | ||
| # This method doesn't modify ARRAY/REPEATED columns. |
There was a problem hiding this comment.
Does this imply a TODO for later, or is the nature of pandas such that arrays are just always an object that gets no special processing?
There was a problem hiding this comment.
Potential TODO, but such a low priority I don't think it's worth calling out. Now that we have https://github.com/googleapis/python-db-dtypes-pandas we have more flexibility in terms of creating dtypes that are more efficient than Python object columns. Though in this case, I'm not sure we'd have any better of an approach than https://github.com/xhochy/fletcher
Yeah, for sure... I'd very much like to give our pandas-gbq users as wide a set of versions as possible, though. Those folks are often stuck in (notebook) environments with some core dependencies locked. |
🤖 I have created a release *beep* *boop* --- ## [0.17.0](v0.16.0...v0.17.0) (2022-01-19) ### ⚠ BREAKING CHANGES * use nullable Int64 and boolean dtypes if available (#445) ### Features * accepts a table ID, which downloads the table without a query ([#443](#443)) ([bf0e863](bf0e863)) * use nullable Int64 and boolean dtypes if available ([#445](#445)) ([89078f8](89078f8)) ### Bug Fixes * `read_gbq` supports extreme DATETIME values such as `0001-01-01 00:00:00` ([#444](#444)) ([d120f8f](d120f8f)) * `to_gbq` allows strings for DATE and floats for NUMERIC with `api_method="load_parquet"` ([#423](#423)) ([2180836](2180836)) * allow extreme DATE values such as `datetime.date(1, 1, 1)` in `load_gbq` ([#442](#442)) ([e13abaf](e13abaf)) * avoid iteritems deprecation in pandas prerelease ([#469](#469)) ([7379cdc](7379cdc)) * use data project for destination in `to_gbq` ([#455](#455)) ([891a00c](891a00c)) ### Miscellaneous Chores * release 0.17.0 ([#470](#470)) ([29ac8c3](29ac8c3)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
🤖 I have created a release *beep* *boop* --- ## [0.17.0](googleapis/python-bigquery-pandas@v0.16.0...v0.17.0) (2022-01-19) ### ⚠ BREAKING CHANGES * use nullable Int64 and boolean dtypes if available (#445) ### Features * accepts a table ID, which downloads the table without a query ([#443](googleapis/python-bigquery-pandas#443)) ([bf0e863](googleapis/python-bigquery-pandas@bf0e863)) * use nullable Int64 and boolean dtypes if available ([#445](googleapis/python-bigquery-pandas#445)) ([89078f8](googleapis/python-bigquery-pandas@89078f8)) ### Bug Fixes * `read_gbq` supports extreme DATETIME values such as `0001-01-01 00:00:00` ([#444](googleapis/python-bigquery-pandas#444)) ([d120f8f](googleapis/python-bigquery-pandas@d120f8f)) * `to_gbq` allows strings for DATE and floats for NUMERIC with `api_method="load_parquet"` ([#423](googleapis/python-bigquery-pandas#423)) ([2180836](googleapis/python-bigquery-pandas@2180836)) * allow extreme DATE values such as `datetime.date(1, 1, 1)` in `load_gbq` ([#442](googleapis/python-bigquery-pandas#442)) ([e13abaf](googleapis/python-bigquery-pandas@e13abaf)) * avoid iteritems deprecation in pandas prerelease ([#469](googleapis/python-bigquery-pandas#469)) ([7379cdc](googleapis/python-bigquery-pandas@7379cdc)) * use data project for destination in `to_gbq` ([#455](googleapis/python-bigquery-pandas#455)) ([891a00c](googleapis/python-bigquery-pandas@891a00c)) ### Miscellaneous Chores * release 0.17.0 ([#470](googleapis/python-bigquery-pandas#470)) ([29ac8c3](googleapis/python-bigquery-pandas@29ac8c3)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
Fixes #365 🦕