Ticket #429 (closed defect: worksforme)

Opened 5 years ago

Last modified 4 years ago

Altering a column to allow NULL fails with sqlite

Reported by: KyleMac Owned by: andrew
Priority: major Milestone: 0.7.3
Component: migrations Version: 0.7
Keywords: Cc:

Description

Using the following to alter a column to allow a null value:

db.alter_column('shop_order', 'completed_on', self.gf('django.db.models.fields.DateTimeField')(null=True, blank=True))

Raises:

sqlite3.OperationalError: SQL logic error or missing database

Which according to: http://www.vijaykiran.com/sqlite3-exception-sql-logic-error-or-missing-database/

The reason for the exception is putting a ‘NULL’ into non NULL column. And SQLite says “missing database”. Way to write the exceptions.

But what this migration is doing is actually the opposite of that, and it even happens with an empty database.

It can be due to the database being locked too but what would cause that? I have alter_columns in preceding and following migrations that are working fine (this one is 10/11).

Change History

comment:1 Changed 5 years ago by KyleMac

I think the actual query that raises the exception appears to be:

PRAGMA index_list("shop_order")

And I think the issue is something to do with running too many migrations at once that involve deleting or changing fields. I can get them all to succeed if I run them in small groups.

comment:2 Changed 5 years ago by KyleMac

The field that is being altered ("completed_on") was added in a previous migration and I think that is the problem. You can't edit a field that has been added until the transaction has been committed.

comment:3 Changed 5 years ago by andrew

  • Status changed from new to assigned
  • Milestone set to 0.7.2

comment:4 Changed 4 years ago by andrew

  • Status changed from assigned to infoneeded
  • Milestone changed from 0.7.2 to 0.7.3

(apologies for the incredibly long delay here)

South commits transactions after every migration has finished running (at least, as long as the backend supports it, which the SQLite backend does). Is this perhaps one bigger migration that both, say, adds and removes and something-elses a field? Could you attach it?

comment:5 follow-up: ↓ 6 Changed 4 years ago by bradwhittington

  • Status changed from infoneeded to assigned

I have come across this issue too, for a simple migration which just adds a column. It barfs the first time it hits the migration, and when I run migrate again it seems to work fine.

comment:6 in reply to: ↑ 5 Changed 4 years ago by andrew

Replying to bradwhittington:

I have come across this issue too, for a simple migration which just adds a column. It barfs the first time it hits the migration, and when I run migrate again it seems to work fine.

Could you attach your example migration? I imagine i's pretty simple, but it will speed up replicating this.

comment:7 Changed 4 years ago by anonymous

I get a different error, but a crashing migration is what I have experienced. I've also seen this when dropping a column after a data migration in #604. I have included a django app with a set of migrations that exhibit the problem.

comment:8 Changed 4 years ago by andrew

See my reply to #604, where I clarify how I can't replicate this locally. I think it might be a platform-specific issue.

comment:9 Changed 4 years ago by andrew

It turns out #604 was caused by an error in the older SQLite libraries, so this may be the same thing. Could you upgrade the sqlite module and try again?

comment:10 Changed 4 years ago by andrew

  • Status changed from assigned to closed
  • Resolution set to worksforme

Closing as worksforme as it seems to be a SQLite library error.

Note: See TracTickets for help on using tickets.