mysql introspection doesn't handle CHAR(n) fields

[Bill Fenner <fenner@…>]

I have a legacy table that has columns like

CREATE TABLE `foo_info` (
  `foo_tag` int(11) NOT NULL auto_increment,
  `record_type` char(8) default NULL,
  `name_prefix` char(10) default NULL,
  `first_name` char(20) default NULL,
...

note: CHAR, not VARCHAR.

"python manage.py inspectdb" turns these into TextFields since it doesn't know any better. They work much better as CharFields; the attached diff makes that happen.

[Bill Fenner <fenner@…>]

Patch for db/backends/mysql/introspection.py

[Bill Fenner <fenner@…>]

A less incorrect diff for introspection.py

[Bill Fenner <fenner@…>]

I missed that the STRING -> TextField mapping was done explicitly. I attached a new patch that changes the existing mapping instead of adding a new one at the end.

CharField is a much better match for STRING than TextField is. Neither one will exactly recreate the original schema with "python manage.py sql", but STRINGs are much closer to VAR_STRINGs than they are to BLOBs.

[Malcolm Tredinnick]

A bit subjective, this one, but I'm inclined to agree that CharField will be more appropriate. The backwards-incompat change is unlikely to bite anybody badly, either.

In future, please make patches from the route of the source tree so that we can see which file is patched (in this case, it's easy enough to work it out, but not always).

[Malcolm Tredinnick]

(In [5042]) Fixed #4048 -- When introspecting a MySQL database, map CHAR(n) fields to
Django's CharField type, not TextField. Thanks, Bill Fenner.