On Apr 17, 9:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > Coercion of the type you describe is not required for any field > currently supported. I would be hesitant to include coercion as a core > part of the framework unless there is a generic need to coerce > database values into Python values in some way other than that > performed by the database backend. Can you provide any use cases other > than your DurationField that require this sort of functionality?
At the moment, DurationField is the only thing I know of that isn't well-served by existing functionality, but I think the point is that DurationField proves that there are potentially new field types that don't line up 1-to-1 with database column names. I don't know what other field types there might be in the future, but it seems like a stretch to think that it's unnecessary just because I can't anticipate other specific uses. That may just be me, though. I wouldn't be opposed to having this functionality somewhere outside the core, but I can't imagine how that would be possible. I don't see any other way to trigger field-specific code, except perhaps to have DurationField's contribute_to_class create a wrapper around the model's __init__, which would then coerce the fields after creating the object. I can't imagine you would consider that a more elegant solution than simply using to_python to do the same. On the other hand, some completely separate framework could be used to do coercion, but that framework would still have to be called within the core, and would have ultimately the same functionality as to_python anyway. Even if to_python wasn't originally intended for this, it seems perfectly suited for this task. > The MySQL backend already contains code to coerce some date fields > (and on mysql_old, boolean fields, too). However, this is handled as a > data-correction interface on the MySQL backend, rather than a > field-level fix. And that works just fine in all situations where the expected Python type is easily identifiable from the the database column type. Unfortunately, DurationField proves this isn't always the case, and it seems strange to assume that nobody will ever want to do interesting things. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
