I think this discussion could use a bit of revival, as it seems
obvious to me that there are groups that could benefit from some sort
of field-level coercion. In addition to my DurationField and the
various possibilities available with GeoDjango, there are other things
that would be useful in various contexts.
Consider a ColorField that could store its value as an INTEGER for
efficiency, but allows Python to access it as a 3-tuple of (red,
green, blue). This could be done for both assignment and retrieval,
with the field dealing with everything in between using to_python and
get_db_prep_save. In fact, something like this is almost possible
already, with get_db_prep_save handling transmission into the
database, and get_db_prep_lookup dealing with lookup types. In theory
(with a good bit of work, I expect) it should be possible to search on
such a color field with something like
Model.objects.filter(color__red_gt=200) to get objects with a lot of
red in their color. That's probably a bad example given the SQL that
would be necessary to look up on part of an INTEGER while ignoring the
rest of it, but it shows what kind of out-of-the-box thinking would be
possible if the one missing component (to_python) were in place to
handle coercion into a proper Python type.
Another example would be a variant of XMLField that gives its contents
to Python as a minidom.Document object.
Now, I'll gladly admit that I'm throwing out possibilities that I,
myself, may not ever need, and I also know that there are ways to work
around this behavior outside the core of Django (like the mixin
examples provided for GeoDjango), and that Django is about solving
problems people actually encounter in the real world. However, for
DurationField at least, I am indeed experiencing this problem in the
real world. Maybe I'm just the first to consider storing audio
information in Django (though I doubt it), but it's a real situation
with real needs. YAGNI certainly doesn't apply here, as I definitely
am Gonna Need It.
I would also argue that while Django's focus on real-world problem-
solving is sound and just, it's getting a lot of criticism from people
who think it's not powerful enough for complex applications. While in
general I disagree with that criticism, things like this do
demonstrate its refusal to deal with what might seem like a very
simple, straightforward feature. I find it very odd that Django has
the capability to add custom field types, while (by design,
apparently) restricting their usefulness.
-Gul
On Apr 18, 8:26 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 4/19/07, jbronn <[EMAIL PROTECTED]> wrote:
>
>
>
> > The GIS branch (GeoDjango) is interested in type coercion.
> > Specifically, PostGIS returns geometries as hex strings to the client
> > -- it would be preferable to have this come into the model as either a
> > different type of string like WKT ("POLYGON ( .. )"), KML
> > ("<Polygon>...</Polygon>") or as a GEOSGeometry() object. For
> > example, say we have a 'ZipCode' model with a PolygonField ('poly'):
>
> Ok. That's the sort of use case I was looking for.
>
> I haven't looked at the GIS branch, and my GIS knowledge from
> university is getting _very_ rusty, so you'll need to help me out a
> little.
>
> How do you handle data input of GIS types? What format is used during
> assignment?
>
> Are you using to_python at all in the GIS branch?
>
> To date, the database backend maintains the philosophy that whatever
> you put in (as a python type) is what you get back. If you put a
> boolean in, you get a boolean out; you put a DateTime in, you get a
> DateTime out. Is this still appropriate in the GIS setting?
>
> Is there a use case for being able to get back data of more than one
> type, or is it possible to get a WKT or KML representation from a
> GEOSGeometry object?
>
> Yours,
> Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
