-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat: Add migration in advance of session properties PR #21703
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
# Generated by Django 4.2.11 on 2024-04-21 21:11 | ||
from django.contrib.postgres.operations import AddConstraintNotValid | ||
from django.db import migrations, models | ||
|
||
|
||
class Migration(migrations.Migration): | ||
dependencies = [ | ||
("posthog", "0403_plugin_has_private_access"), | ||
] | ||
|
||
operations = [ | ||
migrations.RemoveConstraint( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. maybe this is the only written up previous incident from migrations There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i think the drawback we have is even a canary deploy doesn't help us since it's the DB that we lock if something does go wrong but I also don't think we have a good alternative here, this is what Django is going to do to make this change 🙈 probably we need to merge this when the system isn't under load and with someone from infra on hand ready to help fix all the things if it does cause downtime. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (and feel happily foolish if it goes in without incident :)) |
||
model_name="propertydefinition", | ||
name="property_type_is_valid", | ||
), | ||
migrations.AlterField( | ||
model_name="propertydefinition", | ||
name="property_type", | ||
field=models.CharField( | ||
blank=True, | ||
choices=[ | ||
("DateTime", "DateTime"), | ||
("String", "String"), | ||
("Numeric", "Numeric"), | ||
("Boolean", "Boolean"), | ||
("Duration", "Duration"), | ||
], | ||
max_length=50, | ||
null=True, | ||
), | ||
), | ||
migrations.AlterField( | ||
model_name="propertydefinition", | ||
name="type", | ||
field=models.PositiveSmallIntegerField( | ||
choices=[(1, "event"), (2, "person"), (3, "group"), (4, "session")], default=1 | ||
), | ||
), | ||
Comment on lines
+16
to
+38
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IIRC these are not really database changes so they have no effect on the DB There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (i.e. Django lists them as migrations but they are no-op for postgres) |
||
# changed from migrations.AddConstraint. See migration 0405 for where we validate the constraint | ||
AddConstraintNotValid( | ||
model_name="propertydefinition", | ||
constraint=models.CheckConstraint( | ||
check=models.Q(("property_type__in", ["DateTime", "String", "Numeric", "Boolean", "Duration"])), | ||
name="property_type_is_valid", | ||
), | ||
), | ||
] |
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.
are types borked here?
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.
Yeah, it does run locally though