You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 7, 2019. It is now read-only.
When converting an existing models.Model model class to a Versionable model class, defaults are not provided, therefore the user must make decisions as part of makemigration migration step. For the 2 examples below, Versionable should be able to handle these sensibly. For identity fields, it should copy the table's PK field, as this is what it does for new rows in the table. For date fields (example 2) it should be the database "now()" at the time it is run on the database, not a hard-coded value (like timezone.now()) in the migration.
Example 1: Handle new identity column in existing table
You are trying to add a non-nullable field 'identity' to assessment without a default; we can't do that (the database needs something to populate existing rows).Please select a fix: 1) Provide a one-off default now (will be set on all existing rows) 2) Quit, and let me add a default in models.pySelect an option: 1Please enter the default value now, as valid PythonThe datetime and django.utils.timezone modules are available, so you can do e.g. timezone.now()>>> ''
Example 2: Handle new version date column in existing table
You are trying to add a non-nullable field 'version_birth_date' to assessment without a default; we can't do that (the database needs something to populate existing rows).Please select a fix: 1) Provide a one-off default now (will be set on all existing rows) 2) Quit, and let me add a default in models.pySelect an option: 1Please enter the default value now, as valid PythonThe datetime and django.utils.timezone modules are available, so you can do e.g. timezone.now()>>> timezone.now()
When converting an existing
models.Model
model class to aVersionable
model class, defaults are not provided, therefore the user must make decisions as part ofmakemigration
migration step. For the 2 examples below, Versionable should be able to handle these sensibly. Foridentity
fields, it should copy the table's PK field, as this is what it does for new rows in the table. For date fields (example 2) it should be the database"now()"
at the time it is run on the database, not a hard-coded value (liketimezone.now()
) in the migration.Example 1: Handle new
identity
column in existing tableExample 1 Migration File Output
Example 2: Handle new
version date
column in existing tableExample 2 Migration File Output
The text was updated successfully, but these errors were encountered: