On Thu, Sep 30, 2010 at 8:01 PM, Jyrki Pulliainen <jy...@dywypi.org> wrote: > Hi! > > We encountered a possible backwards incompatibility with change 12950 > [1]. This was noticed when upgrading from 1.1.1 to 1.1.2. > > If I understand correctly the change 12950 removes squelching of > ImportErrors from AppCache. AppCache in turn provides reverse- > relations for app introspection, for example in admin interface. This > change now causes the ImportError in one otherwise fine case to > propagate and break the application. > > Funnily enough, this does not break our application per se. The webapp > still continues to work with admin interface fully responsive, doing > all the changes wanted, tests passing etc. This only affects a smaller > worker script that is run via upstart. > > This upstart script imported a single model class (let's say, model > class A) from a single app. However, this models.py file also had > another model (class C) and it's admin definitions (there was actually > no change even if these were moved to separate admin.py, we have a > custom AdminSite object). For some reason importing this single caused > the import error to fire. And as said before this behavior doesn't > surface for example when running ./manage.py runserver, only trying to > start the worker script causes the ImportError. > > Unfortunately this software isn't open source, but I think I can > describe the module layout a bit though: > > Class A -- the "troublemaker" class has a reverse relationship with > class B from another app, ie. class B has ForeignKeyField to A. > Neither of these classes has any admin interface and they're not > registered to the admin site object > Class C -- another model in the same models.py (and app) as Class A. > This is registed to the AdminSite. > > Now, when the worker starts the importing of class A causes > ImportError due to the admin site trying to import stuff in AppCache, > even it is not needed. The models.py it is trying to import when > crashing is the models.py containing the Class B. > > Hopefully this description is even a bit helpful, even though it's a > hard to get the whole picture without the code.
Not really -- I've tried to reproduce the 2 apps and three models you describe, but I don't see any errors on 1.1.1 or 1.1.2. I appreciate that you can't release your actual source code, but if you can generate a minimal test app that reproduces the problem case, that would be very helpful. As I said on twitter, this general class of problem is something we've seen before; however, in all the cases we've been able to identify so far, it's turned out to be a legitimate error that Django was historically (and erroneously) suppressing. Yes, 1.1.2 generates more errors, but that's because 1.1.1 masked legitimate errors, not because 1.1.2 is broken. If you can provide a test case that demonstrates otherwise, we're happy to investigate. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.