3 ms·

And you didn’t even bother to do a query of the actual maximum length value of the columns you were mutating? Or at least query and see the text in there? Basi

And you didn’t even bother to do a query of the actual maximum length value of the columns you were mutating? Or at least query and see the text in there? Basically you just blindly ran the migration on the data and checked if it didn’t fail? The lesson here is not about cleverness unfortunately.

detaro 6y ago
The comment clearly states that they did.
- heavenlyblue 6y ago
  If they did, they would have noticed that the columns were empty (because they were wiped clean for PI data). The parent is either misrepresenting the situation or they didn’t do what they say they did. Also in any production setup, before the migration in the same transaction you would have something along the lines of “check if the column size is larger than and then abort”, because you never know when that can be added while working on the database.
  - aszen 6y ago
    I agree we could have done it a lot differently and safely, I especially like the last point you mentioned that is what would have been the correct way to do it. But this happened as described, a local only script that generated a list of columns to modify then a migration to execute the alter queries for all of them.
aszen 6y ago
I did see some values and found them reasonable, problem of the whole thing was there were atleast 200 or so tables with dozens of columns each and only two or so tables were excluded from being dumped locally. So yes I could have noticed their length 0 if I had looked carefully amidst hundreds of rows but since my faulty logic of prod db = local db didn't even consider this possible I didn't bother. If it had been just 10 to 20 migrations queries that would have been a lot easier to validate but then I wouldn't even have attempted to write a script
- mr_toad 6y ago
  > my faulty logic of prod db = local db didn't It happens. “It worked in dev” is the database equivalent of “worked on my machine”.

detaro 6y ago

The comment clearly states that they did.

heavenlyblue 6y ago
If they did, they would have noticed that the columns were empty (because they were wiped clean for PI data). The parent is either misrepresenting the situation or they didn’t do what they say they did. Also in any production setup, before the migration in the same transaction you would have something along the lines of “check if the column size is larger than and then abort”, because you never know when that can be added while working on the database.
- aszen 6y ago
  I agree we could have done it a lot differently and safely, I especially like the last point you mentioned that is what would have been the correct way to do it. But this happened as described, a local only script that generated a list of columns to modify then a migration to execute the alter queries for all of them.

aszen 6y ago

I did see some values and found them reasonable, problem of the whole thing was there were atleast 200 or so tables with dozens of columns each and only two or so tables were excluded from being dumped locally. So yes I could have noticed their length 0 if I had looked carefully amidst hundreds of rows but since my faulty logic of prod db = local db didn't even consider this possible I didn't bother. If it had been just 10 to 20 migrations queries that would have been a lot easier to validate but then I wouldn't even have attempted to write a script

mr_toad 6y ago
> my faulty logic of prod db = local db didn't It happens. “It worked in dev” is the database equivalent of “worked on my machine”.