> You can avoid those couple of joins by making your referenced table primary > key what > your enum value would have been and simple not joining it.
> In this case you would simply use your referenced table for data integrity > through > foreign constraint enforcement. True, but when defining the tables using an ORM it can be hard to document avoiding those joins, whether they're native (using filter) or (the ones you _really_ want to avoid if possible) created via a queryset on attribute access. It's all perfectly reasonable to do, but a bit excessive when all you want to do is add class LikertScale(IntEnum): STRONGLY_AGREE = 5 AGREE = 4 NEUTRAL = 3 DISAGREE = 2 STRONGLY_DISAGREE = 1 to your data model. > As a result, the decision was taken to provide Operation subclasses > appropriate for > anything needed, but require users to manually add that operation to a > migration where > necessary and ensure the dependency tree works. Similarly and extension is > provided > if you want to use the unaccent lookup. Thanks for the clarification. I hadn't really thought about the mechanics of auto-detection except as a "nice to have". Our custom operations are all run manually, but my thinking was that it would probably have to be auto detected if I was going to push the implementation upstream. On 27 February 2015 at 09:26, Josh Smeaton <josh.smea...@gmail.com> wrote: >> Contributing to contrib.postgres is a possible >> option, but it's not really a postgres specific feature -- almost all >> of the major database vendors support it (sqlite being as always the >> obvious exception). > > > This option worries me. I definitely do not like the idea of building a > feature into contrib.postgres that could be built for the rest of the > database backends too. It seems like a cop-out for doing less work, and > really promotes one built in backend above others. contrib.postgres should > be a place for postgres specific features, not for cutting out other > backends. I'm glad you pointed that out. > > Cheers > > -- > 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/112e6136-25ce-475c-be2a-f218411ee745%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2Bm8oA_b%3DX86%2BxOZWkLAY_2JE0mf6kqqZoC0O4q%3D8jejoeM4aw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
