more fun with custom fields

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

more fun with custom fields

Bryan L. Fordham-2

So I've made some progress on using Points in Django.

In postgres, I added a filter (using Database.register_type) to
automatically convert points to a tuple. That worked really well for
reading the data out.

To store, for example, the tuple (30, 30) as a point I have to call
GeometryFromText('Point(30 30)'), which was getting quoted when it was
run, and thus was breaking (that was the topic of my last message). So I
figured I'd write a get_db_prep_save method to run a query to convert the
tuple to a geometry object and return that, which would have been the
ideal solution as far as I could tell.

It didn't work. After a few minutes of playing with it I realized that my
typecast that made reading the data out so easy kept converting my nice
geometry object back into a tuple. Oops.

So, after some tinkering, this is what I have ended up with: I removed the
typecast, and added a method to transform the geometry object to a tuple.

>>> l=Location.objects.get(pk=4)
>>> l.point
'01010000207320000000000000000044400000000000004440'
>>> l.get_point_as_point()
(40.0, 40.0)

I really don't like that. I'll keep playing with some ideas, but I'd
appreciate any suggestions that would let me do:
>>> l.point
(40.0, 40.0)

On a more general note, is there an accepted way to add fields into
contrib? I'd like to be able to have Django create tables with geometry
columns, and using any typecasts I may end with, without the end user
having to modify the base files. I think this would be useful for folks
when it's done, but I certainly don't think it belongs in django core.

thanks
--B





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: more fun with custom fields

donarb-2

Note that Adrian posted a message some time ago about how he uses  
geometry fields in Postgres and Django for his chicagocrime.org site.  
His post is in this thread:

http://groups.google.com/group/django-users/browse_thread/thread/ 
1fbbaf710996a8aa/8b322b5b68b29fbb?
lnk=gst&q=postgis&rnum=1#8b322b5b68b29fbb

Don



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: more fun with custom fields

Bryan L. Fordham-2

Hi Don. Yeah, I'm actually following Adrian's approach in some code
now. What I want to do, though, is be able to include geometry fields
directly in the model

--B

On Oct 11, 11:52 am, Don Arbow <[hidden email]> wrote:
> Note that Adrian posted a message some time ago about how he uses
> geometry fields in Postgres and Django for his chicagocrime.org site.
> His post is in this thread:
>
> http://groups.google.com/group/django-users/browse_thread/thread/
> 1fbbaf710996a8aa/8b322b5b68b29fbb?
> lnk=gst&q=postgis&rnum=1#8b322b5b68b29fbb
>
> Don


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: more fun with custom fields

Malcolm Tredinnick
In reply to this post by Bryan L. Fordham-2

On Wed, 2006-10-11 at 10:51 -0400, [hidden email] wrote:
[...]
> On a more general note, is there an accepted way to add fields into
> contrib? I'd like to be able to have Django create tables with geometry
> columns, and using any typecasts I may end with, without the end user
> having to modify the base files. I think this would be useful for folks
> when it's done, but I certainly don't think it belongs in django core.

Not at the moment. There are two problems that need solving here (I've
mentioned this before either on this list or django-dev) and they're
both still on my endless TODO list. I'll get to them one day.

(1) For fields that are Python wrappers over existing database fields,
there is a small change that needs to be made to the model attribute
creation so that the data from the database is passed to the Field
sub-class's constructor for converting into the right type. This change
is relatively simple (about two lines of code).

        An example of this is if you make a field called Sudoku, say,
        but the data is stored as a string of 81 characters in the
        database. After retrieving the data, it would be nice if the
        model attribute was actually a Sudoku class instance, rather
        than a seemingly opaque string.
       
(2) For fields that are new database types, it is slightly more fiddly.
We need a way to have them created correctly in the database (possibly
also adding introspection, on the "give an inch and somebody is going to
complain about the rest of the mile being missing" principle). We
possibly need a retrieval mapping function -- imagine if we didn't have
a native date field; how might we implement it as a third-party class --
or possibly just hand off the rest of the work to case (1).

Regards,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: more fun with custom fields

Bryan L. Fordham-2


>Not at the moment. There are two problems that need solving here (I've
>mentioned this before either on this list or django-dev) and they're
>both still on my endless TODO list. I'll get to them one day.
>  
>
I bet your todo list looks like mine 8)

>(1) For fields that are Python wrappers over existing database fields,
>there is a small change that needs to be made to the model attribute
>creation so that the data from the database is passed to the Field
>sub-class's constructor for converting into the right type. This change
>is relatively simple (about two lines of code).
>  
>
I may take a look at this....

>        An example of this is if you make a field called Sudoku, say,
>        but the data is stored as a string of 81 characters in the
>        database. After retrieving the data, it would be nice if the
>        model attribute was actually a Sudoku class instance, rather
>        than a seemingly opaque string.
>  
>
...because it would solve a lot of my problem. In my case, I could call
the function to transform the database's geometry object into something
the user can use and understand

>(2) For fields that are new database types, it is slightly more fiddly.
>We need a way to have them created correctly in the database (possibly
>also adding introspection, on the "give an inch and somebody is going to
>complain about the rest of the mile being missing" principle). We
>possibly need a retrieval mapping function -- imagine if we didn't have
>a native date field; how might we implement it as a third-party class --
>or possibly just hand off the rest of the work to case (1).
>
>  
>
In my case, I don't think I could need this if I had (1). Saving the
data isn't my real problem, it's getting it out into a useful format

thanks for the info
--B


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: more fun with custom fields

Bryan L. Fordham-2

ok, I made this change to the Model.__init__() method. at the very end:

        for i, arg in enumerate(args):
+           if hasattr(self._meta.fields[i], 'translate_from_db') and arg:
+               arg = self._meta.fields[i].translate_from_db(arg)
            setattr(self, self._meta.fields[i].attname, arg)

this just checks to see if the field has a method to translate the value.
In my case, I use it to change the value from
'0101000020732000000000000000003E400000000000003E40' to (30.0, 30.0) which
I think is much nicer.

So, is this something that could reasonably be put into Django? It would
allow me (and others) to add more complex custom fields without having to
modify the Django core code.

--B


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: more fun with custom fields

Malcolm Tredinnick

On Thu, 2006-10-12 at 17:11 -0400, [hidden email] wrote:

> ok, I made this change to the Model.__init__() method. at the very end:
>
>         for i, arg in enumerate(args):
> +           if hasattr(self._meta.fields[i], 'translate_from_db') and arg:
> +               arg = self._meta.fields[i].translate_from_db(arg)
>             setattr(self, self._meta.fields[i].attname, arg)
>
> this just checks to see if the field has a method to translate the value.
> In my case, I use it to change the value from
> '0101000020732000000000000000003E400000000000003E40' to (30.0, 30.0) which
> I think is much nicer.
>
> So, is this something that could reasonably be put into Django? It would
> allow me (and others) to add more complex custom fields without having to
> modify the Django core code.

For those following along at home, we've moved the discussion to the
django-developer's list to hash out the implementation details.

Malcolm



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---