On Thu, May 12, 2011 at 02:49:03PM +0100, Tom Evans wrote: > Hi Michal > > This looks really, really good. A few comments:
Thanks for the response. > Value of a composite field: It should descend from namedtuple. From > 1.4 onwards, Django only supports 2.5+, so it's not necessary to fudge > things for Python 2.4 Ah, great. That would actually make things easier, namedtuple could be used directly without any special class factory. At the time of writing the proposal, IIRC, it wasn't clear 2.4 would be dropped. > unique/unique_together: They should both be supported. unique_together > should raise a PendingDeprecationWarning, and it should disappear > according to the deprecation timeline. unique_together only exists as > a Meta option as there is no field to attach that logic to - now there > is. That's also my point of view, however, there have been objections that I mentioned (having to name the index). That's why I'd like to hear a few more opinions. > I also have a few questions: > > If a model has a composite field that is marked as primary_key=True, > how will this affect instance.pk? Presumably this will now return a > tuple - will this affect automatic URL generation in the admin? The instance.pk property will work the same way as it works for any other field, i. e. it will be an alias for the field with primary_key=True. In this case, the CompositeField. That means, retrieval and assignment will happen using iterables. The admin will handle this by extending quote and unquote -- one character will be picked as a separator (probably comma) and quoted inside the atomic values. Looking at the code, it is already quoted anyway so the only thing that will change is that for models with composite primary keys this character will appear in the primary key value. Michal
signature.asc
Description: Digital signature
