George,
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.
Basica
>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 field
# 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.
But, should eac
I think we're in agreement. The inelegance was just that all the
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
meth
On 11/15/05, Kevin <[EMAIL PROTECTED]> wrote:
> 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, bo
