alter_column has null-ness swapped

[agkish@…]

Looking in alter_column in generic.py, the set_null and drop_null are kinda semantically backwards. The sql.appends are swapped though, so it works out ok.

    alter_string_set_null = 'ALTER COLUMN %(column)s SET NOT NULL'
    alter_string_drop_null = 'ALTER COLUMN %(column)s DROP NOT NULL'
...
        if field.null:
            sqls.append((self.alter_string_drop_null % params, []))
        else:
            sqls.append((self.alter_string_set_null % params, []))

Then in mysql.py, the strings actually do what they say they do. This makes mysql columns the opposite of what they're supposed to be.

    alter_string_set_null = 'MODIFY %(column)s %(type)s NULL;'
    alter_string_drop_null = 'MODIFY %(column)s %(type)s NOT NULL;'

I've included a patch along with a test that shows the problem. In the patch, I swapped the stuff in generic.py to be what I perceive to be sane, and then the MySQL stuff starts working.

[andrew]

The large amounts of tracebacks seem to indicate you've forgotten the tests' 0003_alter_spam migration...

[anonymous]

Whoops. alter_column_null.2.2.diff should be correct.

[andrew]

OK, fixed in [103] and [104]. I had to rewrite null_ok to use basic SQL; the DBAPI introspection appears to consist of only fail when applied to Postgres databases.