I'll be the first to admit that I don't know all the internals of
Django, and I especially don't know why certain decisions were made in
the past. But I appreciate knowing that you understand my reasoning,
and from some your rephrasings, it's clear to me that you really do.
I'm also glad to hear I'm at least somewhat on the right track.
As for Model.__init__, the third question in my original post was
whether there were other places that would need updating, so I'm not
surprised to realize that I missed something important. And yes, the
more I look into this topic, the more I see many inherent flaws with
the patches I've submitted so far.
As for serialization, I haven't worked much with that, but as I work
more on DurationField, I'll look more into it to see if I can come up
with something that'll work for that as well. I guess I still have to
get used to the notion of working with things I don't personally have
a need for, if I want to start suggesting changes that will impact
larger groups of people.
Given the resistance I've had so far with the coercion patch, I've
starting working on a signal-based approach instead, to see if I can
possibly get DurationField working without any patches to other bits
of Django's core. Just to make sure I test everything I should be, I
see the following situations that need to be tested (please let me
know if there are more situations I should be aware of):
* Instantiating an object directly in Python: obj = MyModel(...)
* Storing the object in the database: obj.save()
* Retrieving the object from the database: MyMymodel.objects.get(...)
* Serializing the objects: data = serializers.serialize('xml',
Mymodel.objects.all())
* Deserializing the objects: objs = serializers.serialize('xml', data)
Even as I sit here going back and forth between this post and my
DurationField code, I find that a signal-based approach does in fact
satisfy all those situations, without the coercion patch. At least, it
does for the XML serializer. The JSON one breaks, but I'm using old
Django code here at work, so I'll test it again when I get home before
I submit another patch.
Anyway, I guess I'll just finish by apologizing for being quite as
heated as I was when I sent my last, and now that I found that the
post_init signal seems to do a good job (after all, it pretty much
extends Model.__init__, just like you mentioned), I'll be much less
aggressive on the coercion front. Once I get it tested with Django SVN
at home, I'll put it up so the GeoDjango guys can look at my technique
and see if it would work for their field types as well.
-Gul
On May 10, 10:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-05-10 at 08:14 -0700, Gulopine wrote:
> > I think this discussion could use a bit of revival, as it seems
> > obvious to me that there are groups that could benefit from some sort
> > of field-level coercion. In addition to my DurationField and the
> > various possibilities available with GeoDjango, there are other things
> > that would be useful in various contexts.
>
> > Consider a ColorField that could store its value as an INTEGER for
> > efficiency, but allows Python to access it as a 3-tuple of (red,
> > green, blue). This could be done for both assignment and retrieval,
> > with the field dealing with everything in between using to_python and
> > get_db_prep_save. In fact, something like this is almost possible
> > already, with get_db_prep_save handling transmission into the
> > database, and get_db_prep_lookup dealing with lookup types. In theory
> > (with a good bit of work, I expect) it should be possible to search on
> > such a color field with something like
> > Model.objects.filter(color__red_gt=200) to get objects with a lot of
> > red in their color. That's probably a bad example given the SQL that
> > would be necessary to look up on part of an INTEGER while ignoring the
> > rest of it, but it shows what kind of out-of-the-box thinking would be
> > possible if the one missing component (to_python) were in place to
> > handle coercion into a proper Python type.
>
> > Another example would be a variant of XMLField that gives its contents
> > to Python as a minidom.Document object.
>
> Something your explanation hasn't addressed so far is actually creating
> the right Python types in the models and this surprises me a little. If
> you're doing all this thinking about how to map from database fields to
> special types, surely the Model.__init__ changes need to come into the
> picture so that accessing MyModel.foo returns the right Python type,
> too.
>
> Luckily, we've thought about this before. Most of the core changes
> needed to add extra field types, particularly those that subclass
> existing database types, is essentially. It's about three lines of code
> (there was a patch published on this list or django-users last year,
> from memory). You basically just have to change the place in
> Model.__init__() that assigns the database-retrieved value to a Python
> instance attribute with a call to an init()-like method that acts like
> you are describing for to_python() -- if such a function exists.
>
> Normally I would point you to the exact thread, but I can't seem to
> search it out. In any case, the changes are really trivial. I think
> there was some reason you could just use the __init__ method on the
> class as the "converter to Python instance", but I may be misremembering
>
> The only vaguely tricky part we didn't solve last time was getting this
> to work with serialisation in a reasonably transparent fashion.
>
> The idea was to push pretty much all the work off to the sub-classes. So
> the sub-classes special method (be it called to_python() or whatever)
> would be given the database value and return an instance that proxies
> for that value.
>
> In short, I think your assessment of the situation as far as creating
> new data types that map to database fields is broadly correct.
>
> I haven't looked at the patch you mentioned at the start of this thread
> in detail and won't have time to do so for quite a while yet. I am
> completely buried in Django work in my spare moments and have slightly
> less than zero free time. At a glance, I think the patch needs some
> thinking about whether it's in the right place, since it's clearly doing
> a bit more work each time than the current implementation and function
> calls and pop() calls are not free. Not saying it's wrong, per se, just
> that it's not a no-brainer, either.
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
