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

:mod:`initdb <djangosite.management.commands.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 :srcref:`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 :lino:`/releases/2011/0907` and installed in Eupen.

Another method for initdb
=========================

Another idea I tried for ticket :srcref:`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
:file:`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` :term:`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).

:term:`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`
======================