I think Kevin’s issue is that it takes a huge amount of runtime to create the FK’s select HTML tag - Django having to go through 1M rows before displaying the page. This issue is true in UpdateView CBVs as well.
Changing the situation slightly - I’m talking about just primary keys from here on, not all FK’s. Is there some justification for Django forcing UpdateViews (and admin pages) to have to have the entire set of primary keys displayed and able to be changed? I believe the real world doesn’t operate like that. In SAP or Oracle apps or any other business process, you can’t change the primary key value willy nilly. For example, should an admin at Amazon be able to take my prime order and re-assign it to some other random person? No. And, even if this is a specific business requirement (for example, one subsidiary needs their purchase order transferred to their peer subsidiary), that should be done via a unique exception process that checks all the business rules and circumstances, such as ensuring both companies belong to the same corporation. However, those are exception transactions, not the forced norm. To make this situation work today in Django updates, all applications using an update with a primary key to a large table has to write special form or view __init__() methods to limit primary key or keys shown. Otherwise, you have to wait for the page to build enormous primary key select tags. Why? Jim > On Jan 27, 2021, at 7:07 PM, Mike Dewhirst <mi...@dewhirst.com.au> wrote: > > On 28/01/2021 12:33 am, Kevin Olbrich wrote: >> Hi! >> >> Is it possible to disable fetching of related models for admin pages? >> I have a field that links to a table containing more than 1M rows which >> django tries to fetch and build the drop down. For my purpose, it is >> sufficient if it is a simple input containing the id instead. > > Couple of options ... > > 1. If there is a subset of 1M rows which apply you can filter the drop down > list to just a few - or > > 2. Avoid the issue altogether > > - make the fk field in the model null=True and blank=True > > - make the fk field in the admin readonly > > - add a new integer field for the user-entered value of the desired id > > - in the model save() method[1] find the desired instance from the 1M > rows and put it into the real fk field > > Might work but not tested. This is a thought experiment. > > Mike > > [1] > def save(self, *args, **kwargs): > # might need some adjusting for safety, business rules etc > self.onem = OneM.objects.get(id=self.pseudo_fk) > super().save(*args, **kwargs) > >> >> How can I accomplish this? >> >> Thank you! >> >> Kind regards >> Kevin >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/12a7c928-a960-4c48-b631-93153260adbfn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-users/12a7c928-a960-4c48-b631-93153260adbfn%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > Signed email is an absolute defence against phishing. This email has > been signed with my private key. If you import my public key you can > automatically decrypt my signature and be sure it came from me. Just > ask and I'll send it to you. Your email software can handle signing. > > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/24a0de08-f460-5dea-47d4-df77a5d6170d%40dewhirst.com.au. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9401C7F2-0042-4605-AA9A-E958D2AF0AE5%40hotmail.com.
