fix(metric_alerts): Fix column type of TimeSeriesSnapshot.value to be an array of floats#19502
Conversation
…be an array of floats Initially we implemented this table when we were using south, and it correctly set the column type to `int[]`. When we switched over from South it looks like we broke the type detection of our custom array column, and so going forward new array columns became `text[]`. This means they worked correctly, and we were behaving differently to prod. This means that when we changed this column to float locally it worked fine, since it just stored the floats as text and interpreted them. However in production, postgres is silently converting these values to `int` because it still has an int column type. Adding a quick fix here to correct the column type of this table. There are low thousands of rows here, so it should be fine to convert this over in production. I'll create a task to fix the custom Array column itself later on.
|
This PR has a migration; here is the generated SQL BEGIN;
--
-- Raw SQL operation
--
ALTER TABLE sentry_timeseriessnapshot ALTER COLUMN values SET DATA TYPE float[] USING values::float[];
COMMIT; |
|
If I'm understanding this right..
How many new array columns did we make? Are there others in production that we should be concerned about?
When did we change it to float? |
None, fortunately. We don't use this column much, and actually all other uses of it are just defaulting to
A week or two ago. This doesn't affect anything other than prod, since no one else can use this yet. |
…be an array of floats (#19502) Initially we implemented this table when we were using south, and it correctly set the column type to `int[]`. When we switched over from South it looks like we broke the type detection of our custom array column, and so going forward new array columns became `text[]`. This means they worked correctly, and we were behaving differently to prod. This means that when we changed this column to float locally it worked fine, since it just stored the floats as text and interpreted them. However in production, postgres is silently converting these values to `int` because it still has an int column type. Adding a quick fix here to correct the column type of this table. There are low thousands of rows here, so it should be fine to convert this over in production. I'll create a task to fix the custom Array column itself later on.
3 participants
Initially we implemented this table when we were using south, and it correctly set the column type
to
int[]. When we switched over from South it looks like we broke the type detection of ourcustom array column, and so going forward new array columns became
text[]. This means they workedcorrectly, and we were behaving differently to prod.
This means that when we changed this column to float locally it worked fine, since it just stored
the floats as text and interpreted them. However in production, postgres is silently converting
these values to
intbecause it still has anint[]column type.Adding a quick fix here to correct the column type of this table. There are low thousands of rows
here, so it should be fine to convert this over in production. I'll create a task to fix the custom
Array column itself later on.