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, 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.
Hey Kevin, 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
