Thanks, Josh. I will be cautious if I ever get to taking this on. On Tuesday, February 19, 2019 at 9:55:49 PM UTC-5, Josh Smeaton wrote: > > To add - there's definitely appetite for this feature, but it's a > difficult one, and no one has stepped up to do it. > There are DEP drafts that cover pieces: > > https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst > > https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst > > Citus Data was looking to sponsor development for this feature, and still, > no one with the technical capabilities was willing (or able) to step up: > > https://groups.google.com/forum/#!searchin/django-developers/composite|sort:date/django-developers/wakEPFMPiyQ/ke5OwgOPAQAJ > > I would strongly advise not just running off and attempting something on > your own. Look over the previous attempts and DEPs, and then document your > way forward either by editing the DEP, and by initiating a thread on this > list. > > Cheers > > On Wednesday, 20 February 2019 04:29:41 UTC+11, Dan Davis wrote: >> >> James, >> >> As a Django user I've had this problem often. My best practice ways to >> handle this is as follows: >> >> >> - If the table is read-only, then create a database-level view that >> manufactures a primary key by concatenating the primary key columns >> together. Lie to Django and say this combined column is the primary >> key, >> and keep the Database-level view's model as managed = False at the Django >> level. However, keep the SQL for the view in your git repository, and >> when it changes, build a manual migration - manage.py makemigration >> fooapp >> --empty -n create_replace_bar_view. >> >> >> - If the table is read-write, then either (a) create a view with >> instead of update/instead of insert triggers that manage an underlying >> table, or (b) just add a unique ID and make the existing primary key a >> unique together constraint and index. With the trigger to add a new ID, >> other users of that table shouldn't notice any issues. >> >> >> - Maybe my statement that Django should manage migrations to the >> schema seems unworkable. However, one of the biggest gains you can get >> from >> Django with old schemas like this is to get their DDL into git. Even if >> git >> doesn't do it, make sure some code does it, and it isn't left unmanaged. >> That's been a key challenge and opportunity for me. >> >> >> As a Django developer, I'm a bit green to volunteer to handle this issue, >> but this is exactly the kind of issue that leads me to be a developer - I >> see the ORM and the all-bells included nature of Django as the killer >> combo. I don't have to go outside the farm to have database migrations, >> url routing, etc. It is almost all there. So, please ping back in 3 >> months to see whether I'm up to it. >> >>
-- 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/352490e0-ea4c-4628-9cd9-df8d7c583cb6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
