>This immediately breaks if you extend a field and don't implement that >method. Preferably, all the Field classes would implement the mapping >right there. Each database shouldn't need to know how to map a USState >field for example, just strings, dates and integers, etc.
Can't work. The fields shouldn't know about SQL pecularities. The only sane way to do it is to define a base set of "technical field types" for Django fields that the fields themselves can map to, and then define the mapping of those technical field types to SQL types in the backends. This middle layer of field types would be much more low-level than Django field types (as several different character types for example can map to one technical field type - but remember that even there you have CharField and TextField mapping to two different technical types and SQL types in the end!) and much more abstract than SQL types (because for example we would like to have an IP address technical type, but only can map that directly to SQL with PostgreSQL, but not with other databases). In such a scenario your modified (subclassed) Django field type would just "borrow" the technical field type of it's parent field type. If it needs something else, it would overload the get_field_type method to return something else from the canon of intermediate types. But mapping to SQL specifics would still be done on database level. Boiling it down to SQL base types (as would be another way to do it) doesn't cut it, because we would lose the possibility of non-standard types like IP addresses and would run into funny things with SQL field type TEXT vs. LONG vs. CLOB ... bye, Georg
