Django DEBUG magic, and a bizarre bug under django-extra-views
I have not been able to reproduce the bug I am about to describe when DEBUG is True, whether in production on Apache or locally on the Django dev server. So my first question is: What is all the magic that Django DEBUG does behind the scenes? The documentation doesn't have very much information about this. Now for the bug. I understand that the following description is too bare-bones for anyone to reproduce, but I have IP to protect, and I don't have much hope of the error being reproduced anyway. Suppose I have a Django project with at least two apps, app alice with model A and app bob with model B. I am using UpdateWithInlinesView from django-extra-views. The error occurs when this view constructs a formset from instances of model A. In my email about the 500, I get a message like this: FieldError at /some/url/ Cannot resolve keyword 'field_of_A' into field. Choices are: field_of_B_1, field_of_B_2, field_of_B_3 I've gotten this type of error before. It normally happens when you tell a form "I'm using model C" and "I'm using a field called debbie" and model C doesn't have a field called debbie. That part makes sense. But this error makes it look like it's checking against the field names of model B when it should be checking model A. I have been racking my brain trying to figure out how in the world the construction of a form from one model would consult a different model from a different app. Furthermore, this doesn't happen most of the time, it goes away on server restart, and it doesn't happen under DEBUG = True. So I'm wondering if it's an app registry issue, some sort of race condition that gets the registry out of whack. If so, then I might get somewhere by either understanding the app registry better or understanding what DEBUG does. Any thoughts? -- 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/8d9d6399-e8ee-488f-8f81-b1a6fcd2c9ec%40googlegroups.com.
Re: Django DEBUG magic, and a bizarre bug under django-extra-views
Quick bump to see if anyone has insight on this. On Friday, December 6, 2019 at 5:08:41 PM UTC-6, Alaina Rowe wrote: > > I have not been able to reproduce the bug I am about to describe when > DEBUG is True, whether in production on Apache or locally on the Django dev > server. So my first question is: What is all the magic that Django DEBUG > does behind the scenes? The documentation doesn't have very much > information about this. > > Now for the bug. I understand that the following description is too > bare-bones for anyone to reproduce, but I have IP to protect, and I don't > have much hope of the error being reproduced anyway. > > Suppose I have a Django project with at least two apps, app alice with > model A and app bob with model B. > > I am using UpdateWithInlinesView from django-extra-views. The error occurs > when this view constructs a formset from instances of model A. In my email > about the 500, I get a message like this: > > FieldError at /some/url/ > Cannot resolve keyword 'field_of_A' into field. Choices are: field_of_B_1, > field_of_B_2, field_of_B_3 > > I've gotten this type of error before. It normally happens when you tell a > form "I'm using model C" and "I'm using a field called debbie" and model C > doesn't have a field called debbie. That part makes sense. But this error > makes it look like it's checking against the field names of model B when it > should be checking model A. I have been racking my brain trying to figure > out how in the world the construction of a form from one model would > consult a different model from a different app. > > Furthermore, this doesn't happen most of the time, it goes away on server > restart, and it doesn't happen under DEBUG = True. So I'm wondering if it's > an app registry issue, some sort of race condition that gets the registry > out of whack. If so, then I might get somewhere by either understanding the > app registry better or understanding what DEBUG does. > > Any thoughts? > -- 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/e58145f7-36e6-4240-ae80-37e04bc038a8%40googlegroups.com.
Re: How to display content on a form dynamically when a field value is selected
If the dynamic display changes without the page re-loading, then the best way to do this is with Javascript. Use the Django template to make sure all of the content you might want to show is on the page, and then use JS to change one field on the event of the other field changing. On Thursday, December 12, 2019 at 6:27:27 AM UTC-6, Technical Services at Maitripa College wrote: > > I have a form that displays course codes from a drop-down list. I would > like to display dynamically the content of another field (different for > each course) each time a course code is selected from the drop-down list. > > Thanks in advance! > > alfredo > -- 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/f517e0cf-3923-4ff5-8080-e10ea6dda468%40googlegroups.com.
Re: Django DEBUG magic, and a bizarre bug under django-extra-views
When I get work time to do it, I'll try to post a traceback and some code with renaming to remove project-specific information. I know that building a minimal example that demonstrates the problem would help. The issue with that is, I'd have to get permission to deploy it to our production environment to see if it has the same problem. But that might be worth doing. On Monday, December 16, 2019 at 6:16:25 PM UTC-6, Mike Dewhirst wrote: > > On 17/12/2019 12:19 am, lemme smash wrote: > > i feel for you, but from this description there is no way to figure > > out how to help. it's way too abstract. so you probably may want to > > provide code piece and traceback to get any kind of help here. > > +1 > > It might help to actually build the two-app project alice+bob to try and > prove the problem. Assuming that doesn't prove it, you could then add in > more and more of the existing project until it barfs. > > I've had heaps of experience with similar intractable problems and in > every case (so far) simplifying things and then re-introducing > "features" has proven absolutely that it was my fault. > > YMMV > > > > > On Saturday, December 7, 2019 at 2:08:41 AM UTC+3, Alaina Rowe wrote: > > > > I have not been able to reproduce the bug I am about to describe > > when DEBUG is True, whether in production on Apache or locally on > > the Django dev server. So my first question is: What is all the > > magic that Django DEBUG does behind the scenes? The documentation > > doesn't have very much information about this. > > > > Now for the bug. I understand that the following description is > > too bare-bones for anyone to reproduce, but I have IP to protect, > > and I don't have much hope of the error being reproduced anyway. > > > > Suppose I have a Django project with at least two apps, app alice > > with model A and app bob with model B. > > > > I am using UpdateWithInlinesView from django-extra-views. The > > error occurs when this view constructs a formset from instances of > > model A. In my email about the 500, I get a message like this: > > > > FieldError at /some/url/ > > Cannot resolve keyword 'field_of_A' into field. Choices are: > > field_of_B_1, field_of_B_2, field_of_B_3 > > > > I've gotten this type of error before. It normally happens when > > you tell a form "I'm using model C" and "I'm using a field called > > debbie" and model C doesn't have a field called debbie. That part > > makes sense. But this error makes it look like it's checking > > against the field names of model B when it should be checking > > model A. I have been racking my brain trying to figure out how in > > the world the construction of a form from one model would consult > > a different model from a different app. > > > > Furthermore, this doesn't happen most of the time, it goes away on > > server restart, and it doesn't happen under DEBUG = True. So I'm > > wondering if it's an app registry issue, some sort of race > > condition that gets the registry out of whack. If so, then I might > > get somewhere by either understanding the app registry better or > > understanding what DEBUG does. > > > > Any thoughts? > -- 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/03a43b76-1101-41e6-9ca1-421e57c308ad%40googlegroups.com.