To tell you the truth I couldn't understand some parts of your message, but if your AddictionForm is a ModelForm then you should be able to limit its fields to just the ones you want your users to be able to update.
Regards!
On Thu, Aug 23, 2018 at 8:19 PM Jim Illback <subaru_87@hotmail.com> wrote:
Vijay, you are exactly correct. Thank you much!--
Now, knowing the problem, I still don't have a great solution. Here's how it is supposed to work.
Someone chooses a client from the list or a search. All the possible support records are shown, whether they exist or not, on a screen to hyperlink to one of them. If the record exists, the URL includes the PK and transfers to the UpdateView. This is similar for an AddView if the record does not exist. However, in the Update or Add, I don't want the primary key changed. So, I hid the field (and thus all the records were read). However, now I can't limit that field to only one value. If I format the entire SELECT tag with only one OPTION, Django gives an invalid expression for the ID or Name because it is based on my query set I passed in that fills out the values (ID and name). If I use the form's field value, all the fields are read. Especially on an Add, I don't know a way to fill the client ID field in such a way that Django will take it as valid.
My thoughts on possible solutions:1. Override the get query set method to only pass in the single record - will that work?2. I've been trying to show the field in a <p> tag and override the View's post method by aftering is_valid(), but it always returns invalid expression errors.
What am I missing?
Thanks much again -Jim
On Aug 23, 2018, at 3:48 PM, Vijay Khemlani <vkhemlan@gmail.com> wrote:
Maybe your update form has a field related to a model with thousands of records? like rendering a select combo box with thousands of choices?
On Thu, Aug 23, 2018 at 5:30 PM Jim Illback <subaru_87@hotmail.com> wrote:
I have a Django app in development that performed perfectly with about 20 client records. Each client could have one or more support records and there are 40 potential support records, connected to the client with a ForeignKey (client_id). Then, I loading about 37K client records. Search queries perform almost instantaneously. A paginated list of support records with 40 pages and 10 clients per page comes back in half a second. Great performance.
However, when I click on any record in the list to go to update a specific support record for that specific client (it uses the PK in the URL so is a direct call to the UpdateView routine), I get about 10 second response times and these kind of statistics from Django-debug-toolbar:SQL: 5 queries, 20ms (so clearly not a DB related performance issue)TIME: Resource usage:User CPU time 8827 msecSystem CPU time 137 msecElapsed time 9003 msecContext switches 1 voluntary, 9639 involuntaryBrowser timing:domLoading 9026 (+52130) msec
CACHE: 0 calls in 0.00ms (so clearly not a cache issue either)
Here are some details: Django 2.1, python 3.6.3Hardware: iMac with 32GB, i7 quad coreInstalled apps: Bootstrap3 v9.1.0, crispy forms v1.7.0, easyPDF v0.1.1, registration-redux v2.2, Pillow v4.3.0
Here's one of the specific UpdateView routines being executed - there are only 5 fields in the AddictionForm plus the prime key (no image or file attachments).class AddictionUpdate(PermissionRequiredMixin, UpdateView):
model = Addiction
form_class = AddictionForm
template_name = 'addiction_update.html'
permission_required = 'clientapp.change_addiction'The slow response appears to be on UpdateView pages only, even though all updates are called with the prime key (ID) in the URL. Can anyone give me guidance where to look for improving the performance? Why all the involuntary context switches? Why the large domLoading time?
Thanks in advance -Jim--
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+unsubscribe@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/76F251D2-A429-4700-9F69-053673BDB91F%40hotmail.com.
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+unsubscribe@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/CALn3ei2korG5V3dDcCUQuKiAhG6tzAz%3DJZssNpGJpkAOyKAXpQ%40mail.gmail.com.
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+unsubscribe@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/CE5F73B1-38EC-435B-A7B8-61F143B5C1F2%40hotmail.com.
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+unsubscribe@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/CALn3ei3%2B5NV3Hb5rxO-VYYGbfxRzo1Fi8-mJbXLDFFVpYTrAEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment