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 -~----------~----~----~----~------~----~------~--~---
