On May 11, 10:06 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> My understanding of this whole thread is that the initial resistance was
> because we really do want to understand the use-cases before making any
> architecture change. [...] So if we
> can make that use-case possible without ne
On Fri, 2007-05-11 at 06:46 -0700, Gulopine wrote:
[...]
> Given the resistance I've had so far with the coercion patch, I've
> starting working on a signal-based approach instead, to see if I can
> possibly get DurationField working without any patches to other bits
> of Django's core.
My unders
I'll be the first to admit that I don't know all the internals of
Django, and I especially don't know why certain decisions were made in
the past. But I appreciate knowing that you understand my reasoning,
and from some your rephrasings, it's clear to me that you really do.
I'm also glad to hear I
On Thu, 2007-05-10 at 08:14 -0700, Gulopine wrote:
> 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 Geo
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 vari
Justin Bronn wrote:
> >From GEOSGeometry it is simple to retrieve WKT and HEX, e.g., 'g.wkt'
> or 'g.hex'. However, KML is implemented by PostGIS and can only be
> retrieved if you do "SELECT AsKML(the_geom)" on the database end.
> Further, GML (ancestor to KML, another OGC standard) and SVG can
> How do you handle data input of GIS types? What format is used during
> assignment?
During assignment, PostGIS returns in a format called HEXEWKB
(hereinafter "HEX"), one of its 'canonical forms'. Essentially it's a
hexadecimal string of the binary format (WKB, an OGC standard). For
input you
Russell Keith-Magee 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
>> differ
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 ("POLYGO
On 4/18/07, Gulopine <[EMAIL PROTECTED]> wrote:
>
> On Apr 17, 9:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
> 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 spec
> 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 b
A little more research shows that I could also accomplish what I'm
looking for by tying into the pre_init or post_init signal, but then
I'd need a customized function for each field that needs processing,
on each model. This could be done, of course, and it would certainly
keep this coercion out o
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 Py
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 Py
On 4/17/07, Gulopine <[EMAIL PROTECTED]> wrote:
> My main questions are these:
>
> * Am I right in thinking that Django's to_python method should be used
> for type coercion, rather than relying solely on backend drivers?
Historically, to_python existed for the manipulator framework to
convert t
Hi all,
I had submitted a patch recently (#3982) that forces Django to use the
to_python method of individual fields when retrieving objects from a
database. I'm not being impatient, but I'd like to get some additional
feedback on this, in case I'm going about it all wrong, or if I'm
missing some
16 matches
Mail list logo
