wrote:
> 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.
I managed to create a simulation of the situation (I suggest hitting
the download button or using git, it seems to give the correct
directory structure, the gist is a bit fubar as it doesn't appreciate
directories):
Seems to work exactly like our system does: If the app is started
via ./manage.py runserver it starts up fine and displays the 404. The
admin works fine and I can edit the model C just fine there. However,
if I try to run the runner.py provided in the root directory the
'foobar' newer gets printed and instead the app crashes to an import
error. This is why I'm suspecting there's some difference with the
order of importing stuff and manage.py seems to get the order right.
If I checkout Django version pre-12950 both the admin and runner.py
work just fine (as the ImportError gets swallowed).
- 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-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