On Sun, Apr 03, 2011 at 02:52:01PM -0400, Carl Meyer wrote: > I haven't had time yet to sit down and look at your implementation > questions for a CompositeField (how it works with lookups and Qs, etc), > but I do think that one design goal for a CompositeField implementation > is that we should be able to reimplement the Generic Foreign Key as a > CompositeField. I think your proposal could get there fairly easily -- > all that's needed is for the mapping to and from the Python > representation to be customizable by a CompositeField subclass. So a > namedtuple representation is a sane default, but a GFK implementation > could override that to map to and from actual model objects instead.
The design idea looks good to me. Maybe this could even be done in such a fashion that the following things would work: >>> TaggedItem.objects.filter(content_object=guido) >>> TaggedItem.objects.get(content_object=guido) I'll definitely give it some thought. As I understand it, the problem with these constructs is that the Q object that would be created isn't capable of comparing two actual fields at once and this is exactly what I'm trying to figure out how to do with CompositeFields. Michal Petrucha
signature.asc
Description: Digital signature
