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.
