20110907¶
Lino 1.2.2 has been released¶
I just discovered that I had many of my CharField with null=True. This is just the opposite of what Django wants. Added assertion in Lino kernel to avoid this in the future. https://code.djangoproject.com/ticket/9590
initdb now no longer
displays the disturbing “No fixtures found”. It came from
the implicit flush (or syncdb) command who looked for initial_data fixtures
and never found any (because I prefer std).
I reverted my yesterday’s changes to initdb (see ticket docs/tickets/50). Django’s flush command caused the following error during the database migration:
Error: Database mysite couldn't be flushed. Possible reasons:
* The database isn't running or isn't configured correctly.
* At least one of the expected database tables doesn't exist.
* The SQL was invalid.
Hint: Look at the output of 'django-admin.py sqlflush'. That's the SQL this command wasn't able to run.
The full error: (1146, "Table 'mysite.contacts_roletype' doesn't exist")
This is because Django’s flush tries to delete all tables that should exist, without asking whether they actually do. initdb must work after an upgrade and before the database migration.
Released https://www.lino-framework.org/releases/2011/0907.html and installed in Eupen.
Another method for initdb¶
Another idea I tried for ticket docs/tickets/50, but which turned out to be nonsense (because “flush” only empties all tables does not drop them).
The Django code of the flush command shows that the
sql_flush method of
DatabaseOperations (in
django/db/backends/mysql/base.py )
does quite some tricks and uses SET FOREIGN_KEY_CHECKS.
So it is probably better to use this method.
But Django’s flush django-admin command calls it only
on Django tables
(calls sql_flush with with a hard-coded
only_django=True).
My next idea is to have initdb do exactly what flush does, except for calling sql_flush with only_django=False (and except for the confirmation and calling emit_post_sync).
initdb should now really delete all tables from the database. That may sound dangerous, but that’s what we want when we have a dpy dump to restore our database. You know that you should rather not let Lino and some other application share the same database!