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. My 2 euro-cents here is that starting the server with runserver (or as fastcgi, we've tested that too) does the imports in correct order. It imports the applications and inserts them in sys.modules in orderly fashion without causing any illegal circular import Python can't handle. But when not using the normal startup procedure of manage.py runserver and instead just directly importing one of the models the admin site importing goes fubar and ends up in circular import. The old implementation just swallowed this importerror and let the worker to continue normally. This is the reason why I think this is a change that breaks backwards compatibility in this rare case. For the record, we fixed this, but it caused some extra complexity to our application as we had to split stuff in multiple dummy files for importing certain stuff that previously worked and we also needed to do some overhaul to the way we built our admin site. So everything is now working :) [1] http://code.djangoproject.com/changeset/12950 - Jyrki -- 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.
