I'm not quite sure what that change is supposed to be, but I did try changing "if loading.app_cache_ready():" to "if True:", and that didn't work.
On Nov 17, 11:14 pm, Chris Moffitt <[email protected]> wrote: > Did you try the solution from this > thread?http://groups.google.com/group/satchmo-users/browse_thread/thread/989... > > It worked for me in a slightly different situation but I'm curious if that's > part of the issue. > > Specifically, this point: > On line 47 in satchmo.apps.livesettings.models the cache-miss logic is > calling 'loading.app_cache_ready()' In our case that method is always > returning false. Thus, the database-value is never loaded, and Satchmo > creates a new Setting object in it's place. When this new setting is > saved to the db, it's triggering the IntegrityError. > > I dug into the django.db.models.loading module a bit, and it appears > that a module/app someplace else in our codebase isn't loading > properly, and thus app_cache_ready() never finishes correctly. That > explains why we're seeing the problem in development but the tests > pass. > > So, I'm assuming this isn't a Satchmo problem directly. However, this > _is_ the only side effect we've seen of whatever underlying problem > we're dealing with. The site works fine-as-is otherwise. I'm going to > keep digging, but I thought I'd document what we've found to-date. > > Our temporary fix was to remove the call to 'loading.app_cache_ready > ()' for now. Everything is working as expected. > > -Chris > > On Tue, Nov 17, 2009 at 9:40 PM, davis <[email protected]> wrote: > > I have the same problem (on Apache/mod_wsgi/django1.1). It works fine > > on the test server and via the shell on the production server. I tried > > the "apprentice solution" above, but then it just came up with other > > SettingNotSet errors. > > > If the cache were causing the problem, wouldn't clearing it solve it? > > I tried that, but it didn't help. > > > Has anyone found the solution? > > > On Nov 7, 10:41 am, alej0 <[email protected]> wrote: > > > I try with standalone server and it works but still not in production > > > server which is apache/mod_wsgi/django 1.1. > > > > On Nov 3, 6:32 pm, Gloria W <[email protected]> wrote: > > > > > Did you try running a standalone instance and hitting it directly: > > > > > python manage.py runserver 0.0.0.0:port_number > > > > > so you're eliminating memcache, apache, etc, and you can see if what > > you > > > > suspect, the cache, is the true problem? > > > > > Gloria > > > > > > Anything solutions on this? Has anyone had definitive or even > > marginal > > > > > success eliminating the issue? So far, I've followed all suggestions > > > > > here (short of moving to another webserver -- gotta stick with > > Apache/ > > > > > WSGI). > > > > > > I've been banging my head against the wall for almost a whole day, > > but > > > > > I can't get thatSettingNotSetException to budge. > > > > > > Tried multiple different caching setups. Also verified that > > everything > > > > > works running under shell and development server. I haven't a clue > > > > > what to change in my apache/wsgi configuration. ANY help would be > > > > > appreciated. > > > > > > Thanks, > > > > > Walter > > > > > > On Sep 16, 10:09 am, ruidc<[email protected]> wrote: > > > > > >> We're using Apache 2.2.13 prefork MPM with mod_wsgi 3.0RC4 in daemon > > > > >> mode. > > > > > >> We thought file cache was the issue as well, so switched to > > memcached > > > > >> via python-memcached with default settings, however this did not > > > > >> resolve the issue. > > > > > >> It's coming up on startup or on navigating to admin. > > > > > >> Are there any other suggestions? > > > > > >> I'd hate to move the server over to using Lighttpd or Nginx only to > > > > >> face the same problem there, but if that's the only suggestion, then > > i > > > > >> guess i'll investigate as this problem is a showstopper. > > > > > >> or is there a plan to make this section of the code more resilient > > to > > > > >> cache problems? > > > > > >> Regards, > > > > >> Rui > > > > > >> On Sep 16, 5:43 pm, Bruce Kroeze<[email protected]> wrote: > > > > > >>> On Wed, Sep 16, 2009 at 6:50 AM, ruidc<[email protected]> > > wrote: > > > > > >>>> We're also getting this same problem intermittently, with both > > > > >>>> filecache and memcache. We're using postgres as the database. > > > > > >>>> Corey, did you ever get to the bottom of this? > > > > >>>> Chris, can you offer any other suggestions? > > > > > >>> For some reason, when "things are messed up" in your store, the > > first > > > > >>> symptom seems to be the dreaded "SettingNotSet" disorder. > > > > > >>> In my experience with production sites, the answer is most likely > > one of these: > > > > >>> - You are using mod_python. Stop. Stop now. mod_python stinks. > > Use > > > > >>> mod_wsgi with Apache or preferably move to using Lighttpd or Nginx. > > I > > > > >>> have personally *never* seen a solid, stable, mod_python production > > > > >>> instance in the last two years. > > > > > >>> - Your cache is flaky. If you are using filecache, there could be > > > > >>> permissions issues. > > > > > >>> -- > > > > >>> Bruce Kroezehttp://www.ecomsmith.com > > > > >>> It's time to hammer your site into shape. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Satchmo users" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<satchmo-users%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/satchmo-users?hl=. -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=.
