On Mon, 2007-11-05 at 15:29 +0000, Justin Bronn wrote:
> > (2) The gis branch should really use a better name
than "NoField" here.
> > Not a lot of code calls get_internal_type() -- the
main critical piece
> > being db_type(). In all the cases where
django.contrib.gis overrides
> > get_internal_type(), they are also returning None
from db_type(). So the
> > code should probably use descriptive names for the
internal type.
>
> The "NoField" nomenclature is a result of
legacy implementation. When
> I first implemented the GIS branch there was no
`db_type` method to
> work with. Moreover, I needed an internal type that
wouldn't actually
> create SQL for the column because PostGIS geometry
columns are added
> with a stored procedure. Using "NoField,"
(from what I can tell, now
> only used by ManyToManyFields), allowed me to achieve
the
> functionality without patching django's core code.
Yes, I realise the history. No criticism of the motivation
behind the
approach.
> I commented out the get_internal_type() in my code, and
was able to
> sync the database just fine. Since db_type returns
None,
> get_internal_type() would default to using the parent
class' routine,
> and the expected name (e.g., "PointField")
would be returned. Do you
> see any problems with the approach of simply removing
the
> get_internal_type() routine?
I think that's best, if you're happy with the class name as
the type
(and normally that would be most natural).
Regards,
Malcolm
--
I've got a mind like a... a... what's that thing called?
http://www.pointy-s
tick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-users googlegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
|
