What about calling the attribute something like "constraints" similar to how it's done in SQLAlchemy [1]? For now the attribute can just contain a list of Index() instances but that would also lay grounds for supporting check constraints and other related table level options.
Moritz [1] http://docs.sqlalchemy.org/en/latest/core/constraints.html Am 10. März 2016 09:57:47 MEZ, schrieb "Anssi Kääriäinen" <akaar...@gmail.com>: >On Wed, Mar 9, 2016 at 11:16 PM, akki <aksheshdo...@gmail.com> wrote: >>> >>> Of course, this is a great thing to have. But I wonder if we can do >>> something to prevent pushing non-indexes to the indexes attribute of >>> Meta. Having Meta.indexes = [CheckTypeConstraint(foo__in=['foo', >>> 'bar'])] doesn't read correctly. >> >> >> Perhaps it would be best not to mix constraints and indexes. I would >like to >> know your thoughts on stopping to create indexes explicitly for >unique >> constraints because all database do that automatically because that >only >> gives a performance degradation as far as I know. > >The point is that if the Index class generates the full SQL for the >index creation, then the Index classes can be used to run arbitrary >changes to the database. Having the ability to run arbitrary SQL is >great, but this will lead to users having all sorts of non-indexes in >the indexes meta attribute. I'd like to avoid that if possible. > > - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/34AC0787-76E3-47CB-B3D2-3D87703B7CED%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
