1. Bruce Kroeze
  2. django-livesettings
Issue #21 new

Values are not saved to the database in some situation

Hynek Cernoch
created an issue

Preconditions are typical for situation, when the user solves some problem on the production server:

  • Using 'memecached' before stopping the webserver python process.
  • Database has been reseted or restored from backup or other project with other database have been started after stopping the previous.

Problem: Previous vaues stored in memcached are displayed on the page http://127.0.0.1/settings/ , what is natural and is not so bad and can be even useful. After changing some values, only those new changed are saved. Values which are different between the old and the new database are not updated to values, which are stored by the web form.

It is not significant whether original process and/or database was a normal one or an auxiliary one for the purpose to investigate some problem.

Solution It should be definitely saved the same what was on the form, when "Updatete Settings" have been pressed. \

The best would be to highlight by some color values different between database and cache, when /settings/ are displayed. To display cached values, because it is the most consistent with the behavior of normal server, but to display a link for resetting livesettings in the cache, if there is a difference. (This way also some values from one configuration can be imported to other configuration.)

Comments (10)

  1. Hynek Cernoch reporter

    Other side of the same special bug:

    IntegrityError at /settings/ -- columns site_id, group, key are not unique

    To reproduce:

    • Create two default Satchmo projects by clonesatchmo (with different databases of arbitrary type, the easiest is let it be sqlite3)
      Enable memcached cache.
      We want to play with the value CART_PRECISION "Cart Quantity Decimal Places" (which has a nice default value 0) by the url http://127.0.0.1:8000/settings/ \
    • Start the first project, login.
      Set CART_PRECISION = 1
      Stop the first projest.
    • Start the second project, login.
      Set CART_PRECISION = 0
      Stop the second project.
    • Start the first project, login.
      Set CART_PRECISION = 1
      "IntegrityError at /settings/ -- columns site_id, group, key are not unique"

    Not very frequent, but when debugging a production configuration it is not so absurd example. All packages from the Satchmo family are the newest.

    Also N. B.: Reset memcache! Reset memcache! Reset memcache! ...

  2. drpoovilleorg

    No one has commented on this in a while, but i'm seeing this and it's such a strange and annoying bug.

    For example, if i try to update a setting, the page refreshes upon save and often appears unchanged. Then, if i refresh, the setting magically gets updated. Then if i refresh again, sometimes (randomly in all cases, timing based?) the setting reverts. And so forth, ad nausium.

    I see the integrity error on occasion, but not always.

    I see the issue when running with postgres or mysql.

    I have confirmed it on multiple browsers.

    But it disappears when i run 'manage.py runserver' soo.... i have a sneaking suspicion that it's going to have to do with my webserver setup. Somehow to do with CACHE... but obviously i'm clueless at the moment of the root cause.

    I'm running apache/wsgi, nothing fancy, stock install. Fresh install of everything on top of RHEL 6.1.

    And just FYI, the app that i'm seeing this with is askbot not satchmo. askbot was installed with pip-python (pypi)

    All other functionality works perfectly; it seems to only affect django-livesettings.

    I am not running with memcached

  3. drpoovilleorg

    hmmm.... i don't know the root cause per se, but i found a work around for my own case at least.

    by default, askbot sets CACHE_BACKEND = 'locmem:' CACHE_TIMEOUT = 6000

    I believe this causes troubles though when running in daemon / multi-process mode using apache/wsgi.

    A switch to NOT USING CACHE or better yet, to using memcached instead seems to have cleared up the problem, at least in terms of not hitting the issue that caused the 'integrity error' scenario to play out.

  4. Log in to comment