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 /releases/2011/0907 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 management 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!

Continued on pp2lino