I like that approach to this rather tricky situation. With all my recent work on DurationField, I took a chance at trying to make your code into something generic enough to work for both needs, and possibly others. I'm imagining a FileField that can act as a file-type object, lazily opening the file the first time something calls obj.file_field.read() or obj.file_field.write(). Just an example of what's possible.
Anyway, I noticed that I'm having some trouble with it. First, it looks like it's not truly lazy, since the object is instantiated during __set__, rather than __get__. Since Model.__init__ uses setattr(self, field.attname, val) to assign values to the instance, the descriptor's __set__ method gets triggered as soon as the data is retrieved from the database. At least, that's one it's doing for me. The other issue I'm having is with that of GEOSGeometrys srid attribute. I don't have GeoDjango installed, but I can see what you're trying to do with srid there, and that makes it difficult to make into a generic descriptor. It's easy to pass in an initialization function, but the trick is knowing whether an object has already been initialized within the context of that field. Currently I'm having to call it every time __get__ is called, which can't be a good thing. That's not a problem with the patch as is, of course, just a difficulty I'm having in getting it to work with other Field subclasses. -Marty On May 17, 1:41 am, Robert Coup <[EMAIL PROTECTED]> wrote: > Robert Coup wrote: > > Jeremy Dunck wrote: > > >> In the gis work, we'd like to contribute a fair bit of additional > >> functionality to GIS fields and models with GIS fields. > > >> So far, field contributions seem to be largely done by adding > >> attributes to the model, such as FileField's get_%s_url. > > >> I think this approach may just be legacy from the old codegen days, > >> and I'm not sure this is a good approach when the number of > >> contributions or additional attributes is large. > > >> As an example, I'd like to add GEOS attributes to GIS fields, which > >> includes things like dimensions, area, intersection, boundary, convex > >> hull, etc. > > > If we store the geometry /as/ a GEOSGeometry object, then it already has > > all those attributes/methods on it :) > > > I have done a first stab at lazy-instantiated geometries, which is > > nearly working how I expect it to. I want to look at Gulopine's coercion > > work first, but I'll attach it to a ticket by the end of the weekend so > > you can look at it and see if thats the way we want to head. > > Ok, my lazy-instantiated geometries patch is in there now (#4322) > > It uses a python descriptor to store an internal GEOSGeometry object, > and creates a GEOS object when you assign a text/hex string to it. The > GEOS object is only created on first access, before that it lives as the > string retrieved from the db. > > Because model.my_geometry_field now returns a GEOS object, doing area, > centroid, etc is as simple (and clear) as: model.my_geometry_field.area > > Not sure if it will inspire other creative solutions, but have a look. > > Rob :) > > -- > One Track Mind Ltd. > PO Box 1604, Shortland St, Auckland, New Zealand > Phone +64-9-966 0433 Mobile +64-21-572 632 > Webhttp://www.onetrackmind.co.nz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
