Show FK as input instead of drop down in admin
26 views
Skip to first unread message
Kevin Olbrich
Jan 27, 2021, 8:33:10 AM1/27/21
to Django users
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.
How can I accomplish this?
Thank you!
Kind regards
Kevin
Mike Dewhirst
Jan 27, 2021, 10:08:31 PM1/27/21
to django...@googlegroups.com
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 ...
> 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.
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...@googlegroups.com
> <mailto:django-users...@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.
Jim Illback
Jan 27, 2021, 11:29:06 PM1/27/21
to django...@googlegroups.com
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
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@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.
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
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/24a0de08-f460-5dea-47d4-df77a5d6170d%40dewhirst.com.au.
Mike Dewhirst
Jan 27, 2021, 11:54:37 PM1/27/21
to django...@googlegroups.com
On 28/01/2021 3:28 pm, Jim Illback wrote:
> 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?
Surely that is because Django cannot know what the developer wants. For
> 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?
that reason, Django suggests to write your own get_queryset() and your
own formfield_for_foreignkey() methods in the admin to fetch relevant
data from the database.
In my response to Kevin it was formfield_for_foreignkey() that I was
alluding to in my option #1.
I realise that you have moved on from the Admin in your response above,
but the principle is the same. I should not retrieve more than I need
and I'm the only one who knows what I need.
Cheers
Mike
Ryan Nowakowski
Jan 30, 2021, 1:58:00 PM1/30/21
to Django users
https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.raw_id_fields
Derek
Jan 31, 2021, 9:38:43 AM1/31/21
to Django users
Another option if you want to show actual data, but only a portion, is to use an incremental lookup via an app such https://django-autocomplete-light.readthedocs.io/en/master/ - this works in the Admin as well.
Reply all
Reply to author
Forward
0 new messages