I certainly do hope that it’s filled with more than just junk. If it truly is just junk, scrap it, and create something else. If you are adding a column named “id”, I don’t think there is a need to set managed to False or really do much of anything else with your model. You could rename the columns and tables to match Django conventions.
Something I do with actual “managed = False” models is use a row number window statement to calculate the “id” field in the database view rather than use concatenation. But your way may be faster. Even so, both solutions are handled at the database level, so I’m not sure what changes you are asking about on the manager methods. From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On Behalf Of Dan Davis Sent: Monday, October 29, 2018 2:14 PM To: Django users Subject: Handling Database Tables without a unique column I am currently leading a team handling a 16 year old database filled with junk. I think it has existed since its HTML application was served by Oracle forms. We are in production with Django, and turning off the more recent ColdFusion version this Thursday. However, some of our ways of working reflect the deep SQL roots of the team. For some tables, we have multi-column unique keys. At the time I wrote these things, these seemed the best practices: * For read-only tables, manufacture a unique column through concatenation in a corresponding database view. Base the Django model on the database view. * For read-write tables, do the work of adding a new unique ID column, but keep the table as managed = False. Now that I am better at thinking in querysets, and can regularly use annotations, including F, Subquery and OuterRef expressions, I wonder whether there is a better way. Has anyone ever tried doing this by adding to the SQL expressions code to manufacture a unique column in a QuerySet subclass or in the ModelManager? -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com<mailto:django-users+unsubscr...@googlegroups.com>. To post to this group, send email to django-users@googlegroups.com<mailto:django-users@googlegroups.com>. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e5eedb52-0add-4f3c-902b-4e6e9bfe3d05%40googlegroups.com<https://groups.google.com/d/msgid/django-users/e5eedb52-0add-4f3c-902b-4e6e9bfe3d05%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/64a3b97a215b4a91bd535ad2b10c047b%40ISS1.ISS.LOCAL. For more options, visit https://groups.google.com/d/optout.
