Ticket #700 (closed defect: fixed)
All NOT NULL constraints dropped for a table during migration (sqlite)
| Reported by: | kenj@… | Owned by: | andrew |
|---|---|---|---|
| Priority: | major | Milestone: | 1.0 |
| Component: | migrations | Version: | 0.7.2 |
| Keywords: | Cc: |
Description
I have a model that contains a field that was created with null=False. I later decided it needed to be null=True.
During the migration from one version 0001 to 0002, all of the NOT NULL constraints on all columns are dropped instead of just the single NOT NULL constraint that was supposed to be dropped. This is with a sqlite backend.
In the 0002 migration py file, the following alter command is the culprit
db.alter_column('commands', 'uuid', self.gf('django.db.models.fields.CharField?')(max_length=64, unique=True, null=True))
The DB is still usable but I much appreciate the safety of having backend constraint guarantees. I've already introduced one bug into the system which would have otherwise been caught by these missing NOT NULL constraints.
Attachments
Change History
comment:2 Changed 2 years ago by aarranz@…
Hi,
I've forked your repository and I think I have this issue fixed as all south test except one that fails with "Could insert a negative value into a PositiveIntegerField?." passes when using sqlite3 and NOT NULL constraints are preserved.
However I had to fix another problem. After fixing the NOT NULL problem, I ran the south test and I found that default values are also dropped.
Repository: https://bitbucket.org/aarranz/south-aarranz
branch: bug-700

This is probably due to us really hacking around the SQLite tables, since they have basically no schema alteration of their own. Scheduling for 1.0, but I'd advise using a "real" database as a workaround.