On 12/05/11 12:41, Michal Petrucha wrote: > 1) Leave out the ``unique`` option and live with ``unique_together``. > This would pribably imply also leaving out ``db_index``, otherwise > the API would be a complete mess. > > 2) Allow ``CompositeField.unique`` but also keep ``unique_together``. > The problem I see with this approach is that there would be two > quite different ways to achieve the same effect. > > 3) Make ``CompositeField.unique`` the way to go and deprecate > ``unique_together``. > This way, specifying a unique constraint on a tuple of fields would > work the same way it works on single fields which is IMO a > significant benefit. There's, however, the issue of breaking > backwards compatibility. Furthermore, one would have to add a new > field, albeit virtual, just to create a simple constraint, which > may seem weird to some.
I'd go with (2), we can easily live with these two different ways to do something, because, from a given starting point, there is actually only "one obvious way" to achieve what you want i.e. if you have a composite field already, there is one obvious way to make it unique, and if you have two separate fields, there is one obvious way to make them 'unique together'. > I'm also thinking about implementing an abstract class, VirtualField. > This could be useful mainly as a base class for fields with no direct > database column. That means, it would mainly handle things like > add_to_class (adding itself to the list of virtual fields instead of > local ones), specifying arbitrary lookup filters when asked for one > etc. CompositeField could then be a descendant of this class. > > However, I can't currently imagine any other use-case for this > abstract class than CompositeField. The question is, then, is there > any interest in having an abstract mechanism like this? Can anyone > imagine a use-case? (The question is, should I implement this > functionality directly inside CompositeField or factor it out into > something more general?) Feel free to make such a class if it makes development easier, but keep it private/undocumented until we have at least 2 use cases. Luke -- "Procrastination: Hard work often pays off after time, but laziness always pays off now." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- 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.
