Use django-safemigrate for migrations #11087
Conversation
|
pre-commit fails because we are installing the requirements from main, not from the current file https://github.com/readthedocs/common/blob/e598102991c5a927024f06f187f51f7000e67023/pre-commit-config.yaml#L98-L101 |
readthedocs/integrations/migrations/0013_set_timestamp_fields_as_no_null.py
Show resolved
Hide resolved
| - #. After the deploy has been completed, create a new migration to set the field as non-nullable (let's call this migration ``app 0003``). | ||
| Run this migration on a new deploy, you can mark it as ``Safe.before_deploy`` or ``Safe.always``. |
There was a problem hiding this comment.
Can't this migration be created in the same deploy and marked as after_deploy to make everything in the same deploy?
There was a problem hiding this comment.
Not sure if that will work, but we still need to another deploy to remove all handling of the null case in the code.
| at https://github.com/readthedocs/readthedocs.org/commit/d72ee6e27dc398b97e884ccec8a8cf135134faac. | ||
| """ | ||
| Version = apps.get_model("builds", "Version") | ||
| date = datetime.datetime(2020, 11, 23, tzinfo=datetime.timezone.utc) |
There was a problem hiding this comment.
Shouldn't we use a date that it's obvious it's wrong to avoid confusions here? Like 1999-01-01 or similar.
There was a problem hiding this comment.
I think that would add more confusion, for us and users (if we expose this field).
Closes #10964
📚 Documentation previews 📚
docs): https://docs--11087.org.readthedocs.build/en/11087/dev): https://dev--11087.org.readthedocs.build/en/11087/