Uninitialized choices with runfcgi

Issue #1348 resolved
Hynek Cernoch created an issue

If a new payment is to be added in inline forms to /admi/shop/order/add/ running on a runfcgi server, no payment option is shown, only "--------".

The original report is in: [[http://groups.google.com/group/satchmo-developers/browse_thread/thread/63321a788a49d708|Satchmo developers - iterchoices initialization]]

A symptom is a message in satchmo.log: "iterchoices: Skipped model choices initialization function <shipping_choices> because of model validation (e.g. syncdb)"

This error occurs never with "./manage.py runserver" or "uwsgi" server (which was expected to be enough for testing), it occurs only with "runfcgi".

Comments (7)

  1. Hynek Cernoch reporter
    • changed status to open

    The problem was caused a used compromise, when a fix 2060036504f6 for #1256 have been written, because I could not write more accurate stack introspection formerly.

    New fixed solution 8ace9826fa31 has been tested for many hours. Basic information about testing is in the code.

  2. Chris Moffitt repo owner

    I just realized, this seems to break the unit tests. If you run python manage.py test, does it work for you?

  3. Hynek Cernoch reporter

    I had different results on different machines, but the same results before and after my last change.

    Some bugs look similar to unsolved reports in the user's conference.

  4. Hynek Cernoch reporter

    The problem was only with Django 1.2 not with 1.3, which I am mostly using in the development.

    I wrote shortly a fix but I thought long about. I added and fixed many documentation comments in the source related to the problem. The simple fix is done only by one added word which disables choices based on livesettings in tests.

    It alerted me to a number of problems which should be solved differently in livesettings in the future.

    Fix 5c7e47111759

  5. Hynek Cernoch reporter

    Excuse me, the bug for "python manage.py test" continues. I reproduced it accidentally. I found that it depends on enabled applications and the name of Django directory where Django was compiled. After clonesatchmo it worked after enabling all possible applications it did not work. I have directories django-1.2.3, django-1.3.1 and symbolic link django to one of them. If it was compiled in symbolic link by "python -m compileall ($pwd)" it worked, if cuurent directory at compile time was not exactly django it did not work.

    Fixed 334c2d41128f

  6. Log in to comment