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/e2b080d8-3b0d-49bf-b0b7-d5f1883e98fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  • ... 'Lance Ellinghaus' via Django developers (Contributions to Django itself)
    • ... James Bennett
      • ... Dan Davis
        • ... Josh Smeaton
          • ... Dan Davis
    • ... Simone Federici

Reply via email to