I'm a bit concerned that the DATA_TYPES are hard-coded in the database backends. I think it would preferrable (and more maintainable/robust) to try to define a generic abstract list of data types that match well with the sql variants (text, boolean, integer, etc) instead of directly defining say what a URLField is in each backend.
This came up when I was trying to create a different US State field that used a select box instead of a text column. I extended a SelectField and set the choices to all the possible US states. But when I tried to use it, it complained that my "SelectStateField" was not found in the DATA_TYPES for the MySQL backend. I eventually got around this by overriding get_internal_type() in the Field class, but this is rather inelegant. I think it would be preferrable to define some standard abstract column types like char, text, boolean, date, etc. The backend implementations only have to deal with that smaller list of mappings. Finally, the form field class can define itself based on those abstract types including parameters like length as needed.
