Data Types
Kevin
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.
Adrian Holovaty
> 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.
Yeah, that's exactly what get_internal_type() is for; which part of it
do you think is inelegant?
I agree that we should move more of the DATA_TYPES to
get_internal_type() in the individual Field* class, as much as we can.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
Kevin
builtin Field classes's get_internal_type() just returned
self.__class__.__name__ and expected the database backends to know map
each of those class names.
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.
Keep up the good work...
Jonathan Daugherty
# 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.
But, should each field type know about the various backend types in
order to maintain the mapping?
--
Jonathan Daugherty
http://www.parsed.org
hugo
>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
Kevin
That's exactly what I was insinuating. Provide some abstract sql types
that the Field classes can target as well as the database backends can
implement. There's already distinctions in text vs varchar in the
Fields themselves (CharField vs TextField), so that's already in place.
Basically, you'd just keep the basic data types (CharField, TextField,
Boolean, DateTime, etc) but remove fields like EmailField and such from
the backends and redefine them in the Field.get_internal_type as a
CharField with a maxlength of 75. Just browsing through some of the
backend implementations, it looks like anything not in the
DATA_TYPES_REVERSE is a good canidate for removal.