Re: RESTful Geodjango

2007-11-06 Thread Malcolm Tredinnick 

On Mon, 2007-11-05 at 15:29 +, 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 django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: RESTful Geodjango

2007-11-05 Thread Justin Bronn 

> (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.

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?

-Justin


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

Re: RESTful Geodjango

2007-11-05 Thread Malcolm Tredinnick 

On Sat, 2007-10-20 at 14:01 -0500, Jeremy Dunck wrote:
> On 10/20/07, Ariel Mauricio Nunez Gomez <[EMAIL PROTECTED]> wrote:
> > POINT ( 31.00892404
> ...
> > 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 django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: RESTful Geodjango

2007-10-20 Thread Jeremy Dunck 

On 10/20/07, Ariel Mauricio Nunez Gomez <[EMAIL PROTECTED]> wrote:
> POINT ( 31.00892404
...
> 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 can tell you that the text value inside the  for GIS fields is WKT:
http://en.wikipedia.org/wiki/Well-known_text
There are libraries for pasting it...

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

Re: RESTful Geodjango

2007-10-20 Thread Ariel Mauricio Nunez Gomez 
That restapi is as easy to configure as promised.

The address /xml/mymodel  now presents an xml list  that looks like:


XX-83-297
2007-07-27 14:59:18
POINT (31.00892404 -
82.71686560)
71
1
3


That NoField type, is it ok?

Ariel
PS: Thanks Andreas, and thanks to the geodjango team for your excelent work.

On 10/20/07, Ariel Mauricio Nunez Gomez <[EMAIL PROTECTED]> wrote:
>
> Thanks Justin,
>
> I'll try later and let you know.
>
> Ariel.
>
> On 10/20/07, Justin Bronn <[EMAIL PROTECTED] > wrote:
> >
> >
> > I quickly glanced at the django-rest-interface code and I don't see
> > any reason why it shouldn't work.  There are no plans to combine yet,
> > though it would be nice to have GeoJSON serializers for the GEOS/OGR
> > geometry objects.  The best way to confirm compatibility is experiment
> > yourself!
> >
> > -Justin
> >
> > On Oct 20, 8:57 am, "Ariel Mauricio Nunez Gomez"
> > <[EMAIL PROTECTED]> wrote:
> > > Is it possible/planned to use django-rest-api
> > > [1]in geodjango
> > > [2]  ?
> > >
> > > Ariel
> > >
> > > [1]http://code.google.com/p/django-rest-interface/
> > > [2]http://code.djangoproject.com/wiki/GeoDjango
> >
> >
> > > >
> >

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

Re: RESTful Geodjango

2007-10-20 Thread Ariel Mauricio Nunez Gomez 
Thanks Justin,

I'll try later and let you know.

Ariel.

On 10/20/07, Justin Bronn <[EMAIL PROTECTED]> wrote:
>
>
> I quickly glanced at the django-rest-interface code and I don't see
> any reason why it shouldn't work.  There are no plans to combine yet,
> though it would be nice to have GeoJSON serializers for the GEOS/OGR
> geometry objects.  The best way to confirm compatibility is experiment
> yourself!
>
> -Justin
>
> On Oct 20, 8:57 am, "Ariel Mauricio Nunez Gomez"
> <[EMAIL PROTECTED]> wrote:
> > Is it possible/planned to use django-rest-api
> > [1]in geodjango
> > [2]  ?
> >
> > Ariel
> >
> > [1]http://code.google.com/p/django-rest-interface/
> > [2]http://code.djangoproject.com/wiki/GeoDjango
>
>
> >
>

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

Re: RESTful Geodjango

2007-10-20 Thread Justin Bronn 

I quickly glanced at the django-rest-interface code and I don't see
any reason why it shouldn't work.  There are no plans to combine yet,
though it would be nice to have GeoJSON serializers for the GEOS/OGR
geometry objects.  The best way to confirm compatibility is experiment
yourself!

-Justin

On Oct 20, 8:57 am, "Ariel Mauricio Nunez Gomez"
<[EMAIL PROTECTED]> wrote:
> Is it possible/planned to use django-rest-api
> [1]in geodjango
> [2]  ?
>
> Ariel
>
> [1]http://code.google.com/p/django-rest-interface/
> [2]http://code.djangoproject.com/wiki/GeoDjango


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

[gis] RESTful Geodjango

2007-10-20 Thread Ariel Mauricio Nunez Gomez 
Is it possible/planned to use django-rest-api
[1]in geodjango
[2]  ?

Ariel

[1] http://code.google.com/p/django-rest-interface/
[2] http://code.djangoproject.com/wiki/GeoDjango

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