-
-
Notifications
You must be signed in to change notification settings - Fork 110
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
Rename heat_rate_mmbtu_mwh -> unit_heat_rate_mmbtu_per_mwh
... again
#3029
Rename heat_rate_mmbtu_mwh -> unit_heat_rate_mmbtu_per_mwh
... again
#3029
Conversation
heat_rate_mmbtu_mwh -> heat_rate_mmbtu_mwh_by_unit
... againheat_rate_mmbtu_mwh -> unit_heat_rate_mmbtu_per_mwh
... again
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## rename-core-assets #3029 +/- ##
==================================================
Coverage 88.6% 88.6%
==================================================
Files 91 91
Lines 11019 11021 +2
==================================================
+ Hits 9771 9773 +2
Misses 1248 1248 ☔ View full report in Codecov by Sentry. |
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.
The only question I have is about the alembic migrations that have been changed. Should they really all be getting changed piecemeal like this? Or should the old ones keep referring to the old column name since... old DBs will have the old column name.
Or should we just wipe the migrations out and start anew?
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.
What's up with there being several migration versions in here changing? Including older ones? Is this search-and-replace gone wild? It seems like the older migrations might actually need to refer to the older column name.
Alternatively, should we wipe all the migrations periodically to keep too many layers from building up? Since I don't think we actually intend for it to be possible to migrate between all database versions.
I've occasionally been clobbering and recreating the migrations when branches off of I don't think there is a ton of value keeping all of these small revision changes. Because we're not maintaining the schema of a production database, migrations are mostly helpful on single branches when you adjusting schemas and don't want to rerun the entire ETL to test your changes. |
My concern is that it seems like there's a pre-existing auto-generated migration that's being edited here to use the new column name, which seems a bit odd -- shouldn't the old migration use the old column name? |
Good catch! I must have been a little too trigger-happy and accidentally renamed the columns in old revision files. I deleted |
PR Overview
We renamed the
heat_rate_mmbtu_mwh
column tounit_heat_rate_mmbtu_per_mwh
but merged the changes into a branch that didn't get merged in the main feature branchrename-core-assets
. This PR rebases the changes from #2917 ontorename-core-assets
.PR Checklist
dev
).