Yes, the single biggest problem with Livesettings is that some settings require a reload or a restart. I'd love to see that fixed, at least via an admin message after update.
On Tue, Dec 22, 2009 at 10:49 AM, C <[email protected]> wrote: > I noticed an odd chicken/egg situation with LiveSettings, but I got > too busy to look further at it. > > 1) The loading of certain modules are controlled by values in > LiveSettings. > 2) Items with value in LiveSettings change depending on which modules > are loaded. > 3) For added misery, URLs were (and may still be) one of the things > that depended on LiveSettings. > > The side effect is that the settings appear from the command line > (python and everything satchmo are loaded fresh with the new live > settings), but don't appear within a running satchmo unless it's told > to reload everything. > > The brute force solution might be to raise a signal when certain live > settings are changed and have the handler reload relevant things. But > it gives me a headache just thinking about it. > > Thanks, > Chris Dukes > > > On Nov 22, 7:16 pm, "Eric R. Palakovich Carr" <[email protected]> > wrote: > > I've been having the same problem and I've found a one-line hack that > > doesn't touch the Satchmo source code. From what I can see, the > > product.config module isn't being loaded in the same order as when you > > run the development server. In fact, it isn't being loaded at all > > before the exception is thrown and that is where the product settings > > are loaded. > > > > So add this to your settings.py > > > > # HACK: Fixes SettingNotSet CATEOGORY.SLUG exception that occurs on > > production > > > > import product.config > > > > This resolves the issue, but it doesn't solve the root of the bug. > > I'm new to deploying software using wsgi on Apache, what would be the > > difference in loading modules between django's development server and > > mod_wsgi? > > > > - Eric Palakovich Carr > > > > On Nov 19, 12:22 pm, davis <[email protected]> wrote: > > > > > If Gloria's fix solves it, then there must be something broken about > > > the livesettings configuration module, because 'category' and > > > 'product' are the default settings in product/config.py, and they > > > should be returned if those two slugs aren't set in the livesettings > > > table. > > > > > On Nov 3, 11:52 pm, Gloria W <[email protected]> wrote: > > > > > > My apprentice is playing with this, and he tried this solution, which > > > > worked. His fix: > > > > > > "What I ended up doing was manually adding in the slug values (in the > > > > form of an extra parameter that specified a default) that should > > > > havebeen retrieved by the config_value call that was throwing the > error. > > > > Here are the changes I made to Satchmo's products/urls/__init__.py: > > > > > > # catbase = r'^' + config_value('PRODUCT','CATEGORY_SLUG') + '/' > > > > catbase = r'^' + config_value('PRODUCT','CATEGORY_SLUG', 'category') > + '/' > > > > # prodbase = r'^' + config_value('PRODUCT','PRODUCT_SLUG') + '/' > > > > prodbase = r'^' + config_value('PRODUCT','PRODUCT_SLUG', 'product') + > '/' > > > > > > After those changes, test2.xxxxxxxxxx.com started working again" > > > > > > I am wondering why the slug values weren't there in the first place, > but > > > > I haven't had time to look at it just yet. > > > > > > Gloria > > > > > > > Interestingly enough, I just ran into a somewhat similar error as > > > > > described in this thread - > > > > > > http://groups.google.com/group/satchmo-users/browse_thread/thread/989... > > > > > > > If I try the fix that Brian Tol proposes, I think it resolves my > > > > > issue. It might fix yours. If it does, it would be interesting to > see > > > > > if that's the issue. Please let us know. > > > > > > > -Chris > > > > > > > On Tue, Nov 3, 2009 at 3:32 PM, Gloria W <[email protected] > > > > > <mailto:[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 that SettingNotSet Exception 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] > > > > > <mailto:[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] > > > > > <mailto:[email protected]>> wrote: > > > > > > > >>> On Wed, Sep 16, 2009 at 6:50 AM, ruidc< > [email protected] > > > > > <mailto:[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< > http://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=en. > > > -- Bruce Kroeze http://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]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
