> 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-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment