Temporary hack to work with partition values stored as yyyy-MM-dd but represented as yyyyMMdd in information schema in bq. #175
Conversation
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
WalkthroughThe pull request modifies the Changes
Possibly related PRs
Suggested reviewers
Poem
Warning Review ran into problems🔥 ProblemsGitHub Actions: Resource not accessible by integration - https://docs.github.com/rest/actions/workflow-runs#list-workflow-runs-for-a-repository. Please grant the required permissions to the CodeRabbit GitHub App under the organization or repository settings. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
tchow-zlai
reviewed
Jan 7, 2025
cloud_gcp/src/main/scala/ai/chronon/integrations/cloud_gcp/BigQueryFormat.scala
Outdated
Show resolved
Hide resolved
4 tasks
… represented as yyyyMMdd in information schema in bq.
…we're already doing the date formatting.
david-zlai
force-pushed
the
davidhan/temp_hack_date_format_raw
branch
from
01a81dd to
0a2ea05
Compare
david-zlai
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
cloud_gcp/src/main/scala/ai/chronon/integrations/cloud_gcp/BigQueryFormat.scala (2)
151-153: Track this technical debt.Create a ticket to standardize on
yyyyMMddformat for future BigQuery data storage.Want me to create a GitHub issue to track this technical debt?
162-167: Remove misleading comment about hardcoded format.The
"yyyyMMdd"format must match BigQuery's INFORMATION_SCHEMA format - it's not something we can change.- "yyyyMMdd" // Note: this "yyyyMMdd" format is hardcoded but we need to change it to be something else. + "yyyyMMdd" // Note: this matches BigQuery's INFORMATION_SCHEMA.PARTITIONS format
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro (Legacy)
📒 Files selected for processing (1)
cloud_gcp/src/main/scala/ai/chronon/integrations/cloud_gcp/BigQueryFormat.scala(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: scala_compile_fmt_fix
🔇 Additional comments (2)
cloud_gcp/src/main/scala/ai/chronon/integrations/cloud_gcp/BigQueryFormat.scala (2)
15-15: LGTM! Import required for date formatting.
154-154: LGTM! Good use of Spark configuration for format flexibility.
tchow-zlai
approved these changes
Jan 8, 2025
tchow-zlai
pushed a commit
that referenced
this pull request
Jan 9, 2025
… represented as yyyyMMdd in information schema in bq. (#175) ## Summary We noticed a discrepancy of the date format between partitions in INFORMATION_SCHEMA.PARTITIONS in bigquery vs how it's represented in the actual bq table. in particular, we see that the raw bq table will have `ds` in `yyyy-MM-dd` but for some reason BQ will represent that `ds` partition id in INFORMATION_SCHEMA.PARTITIONS to be formatted as `yyyyMMdd` (no dashes). To work around this, we're coding with the assumption that partition ids in INFORMATION_SCHEMA.PARTITIONS to be `yyyyMMdd`. ## Checklist - [ ] Added Unit Tests - [ ] Covered by existing CI - [ ] Integration tested - [ ] Documentation update --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1209110958473706 Co-authored-by: Thomas Chow <[email protected]>
4 tasks
tchow-zlai
added a commit
that referenced
this pull request
Jan 9, 2025
## Summary - do some date formatting because the input partitions may be of `DATE` type, so we need to normalize them to a string. - inline some options for bigquery writes for now, will follow up with more abstracted handling. See: #175 ## Checklist - [ ] Added Unit Tests - [x] Covered by existing CI - [ ] Integration tested - [ ] Documentation update <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Refactor** - Updated partition column and format handling in DataFrame processing. - Modified visibility of `partitionFormat` to improve package-level access. - Removed optional write format variable from TableUtils. These changes enhance the functionality of data processing utilities by refining how partition columns are managed and accessed within the Spark extensions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> <!-- av pr metadata This information is embedded by the av CLI when creating PRs to track the status of stacks when using Aviator. Please do not delete or edit this section of the PR. ``` {"parent":"main","parentHead":"","trunk":"main"} ``` --> --------- Co-authored-by: Thomas Chow <[email protected]>
4 tasks
This was referenced Feb 8, 2025
4 tasks
kumar-zlai
pushed a commit
that referenced
this pull request
Apr 25, 2025
… represented as yyyyMMdd in information schema in bq. (#175) ## Summary We noticed a discrepancy of the date format between partitions in INFORMATION_SCHEMA.PARTITIONS in bigquery vs how it's represented in the actual bq table. in particular, we see that the raw bq table will have `ds` in `yyyy-MM-dd` but for some reason BQ will represent that `ds` partition id in INFORMATION_SCHEMA.PARTITIONS to be formatted as `yyyyMMdd` (no dashes). To work around this, we're coding with the assumption that partition ids in INFORMATION_SCHEMA.PARTITIONS to be `yyyyMMdd`. ## Checklist - [ ] Added Unit Tests - [ ] Covered by existing CI - [ ] Integration tested - [ ] Documentation update --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1209110958473706
kumar-zlai
pushed a commit
that referenced
this pull request
Apr 25, 2025
## Summary - do some date formatting because the input partitions may be of `DATE` type, so we need to normalize them to a string. - inline some options for bigquery writes for now, will follow up with more abstracted handling. See: #175 ## Checklist - [ ] Added Unit Tests - [x] Covered by existing CI - [ ] Integration tested - [ ] Documentation update <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Refactor** - Updated partition column and format handling in DataFrame processing. - Modified visibility of `partitionFormat` to improve package-level access. - Removed optional write format variable from TableUtils. These changes enhance the functionality of data processing utilities by refining how partition columns are managed and accessed within the Spark extensions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> <!-- av pr metadata This information is embedded by the av CLI when creating PRs to track the status of stacks when using Aviator. Please do not delete or edit this section of the PR. ``` {"parent":"main","parentHead":"","trunk":"main"} ``` --> --------- Co-authored-by: Thomas Chow <[email protected]>
kumar-zlai
pushed a commit
that referenced
this pull request
Apr 29, 2025
… represented as yyyyMMdd in information schema in bq. (#175) ## Summary We noticed a discrepancy of the date format between partitions in INFORMATION_SCHEMA.PARTITIONS in bigquery vs how it's represented in the actual bq table. in particular, we see that the raw bq table will have `ds` in `yyyy-MM-dd` but for some reason BQ will represent that `ds` partition id in INFORMATION_SCHEMA.PARTITIONS to be formatted as `yyyyMMdd` (no dashes). To work around this, we're coding with the assumption that partition ids in INFORMATION_SCHEMA.PARTITIONS to be `yyyyMMdd`. ## Checklist - [ ] Added Unit Tests - [ ] Covered by existing CI - [ ] Integration tested - [ ] Documentation update --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1209110958473706
kumar-zlai
pushed a commit
that referenced
this pull request
Apr 29, 2025
## Summary - do some date formatting because the input partitions may be of `DATE` type, so we need to normalize them to a string. - inline some options for bigquery writes for now, will follow up with more abstracted handling. See: #175 ## Checklist - [ ] Added Unit Tests - [x] Covered by existing CI - [ ] Integration tested - [ ] Documentation update <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Refactor** - Updated partition column and format handling in DataFrame processing. - Modified visibility of `partitionFormat` to improve package-level access. - Removed optional write format variable from TableUtils. These changes enhance the functionality of data processing utilities by refining how partition columns are managed and accessed within the Spark extensions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> <!-- av pr metadata This information is embedded by the av CLI when creating PRs to track the status of stacks when using Aviator. Please do not delete or edit this section of the PR. ``` {"parent":"main","parentHead":"","trunk":"main"} ``` --> --------- Co-authored-by: Thomas Chow <[email protected]>
4 tasks
chewy-zlai
pushed a commit
that referenced
this pull request
May 15, 2025
… represented as yyyyMMdd in information schema in bq. (#175) ## Summary We noticed a discrepancy of the date format between partitions in INFORMATION_SCHEMA.PARTITIONS in bigquery vs how it's represented in the actual bq table. in particular, we see that the raw bq table will have `ds` in `yyyy-MM-dd` but for some reason BQ will represent that `ds` partition id in INFORMATION_SCHEMA.PARTITIONS to be formatted as `yyyyMMdd` (no dashes). To work around this, we're coding with the assumption that partition ids in INFORMATION_SCHEMA.PARTITIONS to be `yyyyMMdd`. ## Checklist - [ ] Added Unit Tests - [ ] Covered by existing CI - [ ] Integration tested - [ ] Documentation update --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1209110958473706
chewy-zlai
pushed a commit
that referenced
this pull request
May 15, 2025
## Summary - do some date formatting because the input partitions may be of `DATE` type, so we need to normalize them to a string. - inline some options for bigquery writes for now, will follow up with more abstracted handling. See: #175 ## Checklist - [ ] Added Unit Tests - [x] Covered by existing CI - [ ] Integration tested - [ ] Documentation update <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Refactor** - Updated partition column and format handling in DataFrame processing. - Modified visibility of `partitionFormat` to improve package-level access. - Removed optional write format variable from TableUtils. These changes enhance the functionality of data processing utilities by refining how partition columns are managed and accessed within the Spark extensions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> <!-- av pr metadata This information is embedded by the av CLI when creating PRs to track the status of stacks when using Aviator. Please do not delete or edit this section of the PR. ``` {"parent":"main","parentHead":"","trunk":"main"} ``` --> --------- Co-authored-by: Thomas Chow <[email protected]>
chewy-zlai
pushed a commit
that referenced
this pull request
May 16, 2025
…MM-dd but represented as yyyyMMdd in information schema in bq. (#175) ## Summary We noticed a discrepancy of the date format between partitions in INFORMATION_SCHEMA.PARTITIONS in bigquery vs how it's represented in the actual bq table. in particular, we see that the raw bq table will have `ds` in `yyyy-MM-dd` but for some reason BQ will represent that `ds` partition id in INFORMATION_SCHEMA.PARTITIONS to be formatted as `yyyyMMdd` (no dashes). To work around this, we're coding with the assumption that partition ids in INFORMATION_SCHEMA.PARTITIONS to be `yyyyMMdd`. ## Cheour clientslist - [ ] Added Unit Tests - [ ] Covered by existing CI - [ ] Integration tested - [ ] Documentation update --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1209110958473706
chewy-zlai
pushed a commit
that referenced
this pull request
May 16, 2025
## Summary - do some date formatting because the input partitions may be of `DATE` type, so we need to normalize them to a string. - inline some options for bigquery writes for now, will follow up with more abstracted handling. See: #175 ## Cheour clientslist - [ ] Added Unit Tests - [x] Covered by existing CI - [ ] Integration tested - [ ] Documentation update <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Refactor** - Updated partition column and format handling in DataFrame processing. - Modified visibility of `partitionFormat` to improve paour clientsage-level access. - Removed optional write format variable from TableUtils. These changes enhance the functionality of data processing utilities by refining how partition columns are managed and accessed within the Spark extensions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> <!-- av pr metadata This information is embedded by the av CLI when creating PRs to traour clients the status of staour clientss when using Aviator. Please do not delete or edit this section of the PR. ``` {"parent":"main","parentHead":"","trunk":"main"} ``` --> --------- Co-authored-by: Thomas Chow <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
We noticed a discrepancy of the date format between partitions in INFORMATION_SCHEMA.PARTITIONS in bigquery vs how it's represented in the actual bq table.
in particular, we see that the raw bq table will have
dsinyyyy-MM-ddbut for some reason BQ will represent thatdspartition id in INFORMATION_SCHEMA.PARTITIONS to be formatted asyyyyMMdd(no dashes).To work around this, we're coding with the assumption that partition ids in INFORMATION_SCHEMA.PARTITIONS to be
yyyyMMdd.Checklist