On Thu, May 12, 2011 at 8:49 AM, Tom Evans <tevans...@googlemail.com> wrote: > 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.
while i'm +1 about using unique on the composite field, i'm -0 about deprecating unique_together. there are times when i want to ensure composite uniqueness but don't consider those fields as part o a composite. in those cases, i wouldn't want to define the composite field just to say its unique. yes, i know about the Python Zen on "only one obvious way", but in this case it seems to be two semantically different things (even if the generated SQL is the same). for me, readability wins -- Javier -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
