Comments on: FuzzyDates, or: One Django Model Field, multiple database columns http://blog.elsdoerfer.name/2008/01/08/fuzzydates-or-one-django-model-field-multiple-database-columns/ Contributing back to the Google Index. Wed, 11 Aug 2010 13:02:07 +0200 http://wordpress.org/?v=2.8 hourly 1 By: admin http://blog.elsdoerfer.name/2008/01/08/fuzzydates-or-one-django-model-field-multiple-database-columns/comment-page-1/#comment-7 admin Wed, 09 Jan 2008 17:20:35 +0000 http://blog.elsdoerfer.info/2008/01/08/fuzzydates-or-one-django-model-field-multiple-database-columns/#comment-7 Thanks for your comment, Malcolm. I haven't looked at generic relations at all so far, which is something I know regret. I wasn't aware that they need to deal with the same issue. I'll check them out. Thanks for your comment, Malcolm.

I haven't looked at generic relations at all so far, which is something I know regret. I wasn't aware that they need to deal with the same issue. I'll check them out.

]]> By: Malcolm Tredinnick http://blog.elsdoerfer.name/2008/01/08/fuzzydates-or-one-django-model-field-multiple-database-columns/comment-page-1/#comment-5 Malcolm Tredinnick Tue, 08 Jan 2008 23:33:46 +0000 http://blog.elsdoerfer.info/2008/01/08/fuzzydates-or-one-django-model-field-multiple-database-columns/#comment-5 Well done. This is a very logical approach. The SubfieldBase metaclass is just a helper class for the common case; it's not required to use it and people *should* just write their own __get__ and __set__ methods when they need to, as you've done. Making this work in the fully general case (where lookups work) is actually pretty fiddly. I've been working on a design for a couple of weeks now without having anything brilliant pop out (although it seems to be getting closer). So it's work in progress. We need it for reverse-lookups with generic relations for example -- which map two database columns to one model attribute. Well done. This is a very logical approach. The SubfieldBase metaclass is just a helper class for the common case; it's not required to use it and people *should* just write their own __get__ and __set__ methods when they need to, as you've done.

Making this work in the fully general case (where lookups work) is actually pretty fiddly. I've been working on a design for a couple of weeks now without having anything brilliant pop out (although it seems to be getting closer). So it's work in progress. We need it for reverse-lookups with generic relations for example -- which map two database columns to one model attribute.

]]>