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.

Reply via email to