Hi all, doing a bit of yak shaving here.
I'm currently refactoring Django's lazy operations [0], and ran into a bit of a snag which led me to make some changes to SQLite's schema editor. All the tests pass, but I thought I should bring this up here to get a few more eyeballs on my changes since it's a pretty critical bit of Django infrastructure.
Explanation:
SQLite requires creating a new table for many schema alterations.
At present the process is:
- define a dummy model with the updated definition and table name "app_model__new"
- create that model's table
- copy the data from "app_model" into "app_model__new"
- delete the "app_model" table
- rename "app_model__new" to "app_model"
Consider a model with a foreign key to self called "parent". In master, that field on the dummy model actually points to the original model, with the correct table name. After the refactor, the dummy model is internally consistent, i.e. its parent field points at itself, with its temporary table name. After you create the new table "app_model__new" and rename it to "app_model", its definition is left with a dangling reference to "app_model__new".
An equivalent way to do this is:
- define a dummy model with the updated definition and the existing table name "app_model"
- rename "app_model" to "app_model__old"
- create the dummy model's table
- copy the data from "app_model__old" to "app_model"
- delete the "app_model__old" table
This avoids ever having a model with a db_table set to the temporary table name. As well as fixing my problem, this seems a little more straightforward – there's a bit of awkward search-and-replace happening with the "__new" table name in the schema editor which we avoid this way.
Cheers,
Alex