On Sat, 2007-10-20 at 14:01 -0500, Jeremy Dunck wrote: > On 10/20/07, Ariel Mauricio Nunez Gomez <[EMAIL PROTECTED]> wrote: > > <field type="NoField" name="point">POINT ( 31.0089240000000004 > ... > > That NoField type, is it ok? > > Well, it depends what you're going to do with it. :) > > That 'NoField' comes from > django.db.models.fields.Field.get_internal_type. It was originally > used during table creation (as in manage.py syncdb) and introspection. > It is also included when serializing objects (as the REST interface > does), but it appears to be only serving as an annotation for > convenience-- it's not actually used in deserialization. > > The problem you may run into is that there are various types of GIS > fields, all of which will return NoField. Further, other custom field > types may return NoField and not actually be GIS fields. Again, this > doesn't affect Django-proper, but if you need to do something > intelligent based on the type attribute, you may have trouble. > > ...A simple solution to fix Django on this issue isn't immediately > apparent. I know Malcolm was noodling on improving Field subclassing, > and this get_internal_type bit is one thing that needs improvement.
I was looking at this today as I was writing all the documentation for field subclassing. Two things sort of became clear: (1) It's usually not going to be a problem beyond a display one. Nothing uses the "type" field inside Django and if external code wants to use it, it can get the real field type by introspecting the model class. (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. (Don't worry, I'll file a ticket about that last part shortly.) I'm also about to commit a whole bunch of field subclassing stuff -- mostly documentation -- and this includes a barrier to catch cases where get_internal_type() returns something not in the db_types list. Then db_type() will return None. The idea here is that if you are creating a field which doesn't use Django's standard code to create the database column, then you can implement get_internal_type() to return your own (non-standard) value and everything else will Just Work(tm). Regards, Malcolm -- The only substitute for good manners is fast reflexes. 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 -~----------~----~----~----~------~----~------~--~---
