fix: Update migration logic in #27119#28422
Conversation
7be1b00 to
f08975a
Compare
|
Tagging as "may require downtime" knowing that mysql takes table-level lock for this type of operation and that this table tend to get large, and is busy with polling (sqllab client poking at query status). |
f08975a to
91ceda7
Compare
|
Thanks for fixing that @john-bodley 🙏🏼 |
|
@john-bodley Before merging this PR, can you do the additional improvement of adding a |
91ceda7 to
5de9bea
Compare
| schema = Column(String(256)) | ||
| catalog = Column(String(256), nullable=True, default=None) | ||
| sql = Column(MediumText()) | ||
| sql = Column(LongText()) |
There was a problem hiding this comment.
@john-bodley Just to confirm.. is sql LongText or MediumText? The reason I'm asking is because it's not being affected by your script.
There was a problem hiding this comment.
Per here sql is LongText and isn't impacted by any of the aforementioned migrations.
5de9bea to
2fdb734
Compare
b3809d7 to
1bd4679
Compare
1bd4679 to
67a0522
Compare
67a0522 to
2fbc926
Compare
|
Given we can't cherry-pick new migrations, I thought it would be prudent to break this PR into two,
as that way we can cherry-pick (1) into the 4.0 branch. |
SUMMARY
I realize it's generally perceived as poor form to change an existing migration, however per here the
query. executed_sqlandquery. select_sqlwere previously defined as typeLONGTEXTrather thanTEXT, thus #27119 resulted in:MEDIUMTEXTcould result in data loss.querytable unnecessarily can be rather expensive given the size of the table.This PR remove mutating these columns unnecessarily.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
TESTING INSTRUCTIONS
Tested the migration using a MySQL metadata database.
ADDITIONAL INFORMATION