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-stick.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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
