On Thu, Apr 07, 2011 at 12:38:07AM +0200, Johannes Dollinger wrote: > The only downside is that you'll have to pick a name for the index – > even if you don't really care (that's historically been a problem > with `related_name`). But anyway, since Meta.unique_together > probably cannot be deprecated any time soon, that's just a -0 from > me.
You're right, having to choose a name for an index might seem weird. Maybe the deprecation of unique_together wouldn't be necessary. This reminds me of a certain comment in the related fields code, [1] > I don't want to push my proposal into your GSoC project. It'd > require more thought and discussion before I'd suggest that. > To address your concern: fields are a central component of the ORM. > But currently, instead of using methods to encapsulate field > specific logic, everything is stuffed in a single monolithic class > (Query), that has to know every possible field implementation. This > leads to code that is hard to maintain and requires coupling with > code that needs more control than standard fields (read: > contenttypes). > And since `add_lookup` and a bit of public API on Query would make > it possible to implement most of your proposal without touching > Django, I wanted to propose it soon enough to have a possible > influence on design decisions. There is certainly a point in this. On the other hand, moving some of the SQL logic would make life harder for the guys fighting on the non-relational backend front. I don't know much about the state of this area though... > Regardless, I look forward to CompositeFields. Good luck with your > application! Thanks. (-; Michal [1] http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L1087
signature.asc
Description: Digital signature
