Configuration and caching

[CraigH]

I'm seeing in issue in satchmo with the payment choices in the
OrderPayment model. What's happening is that payment_choices is
called when the contact.models module is first loaded, which
ultimately calls find_setting (in configuration.models) to retrieve
the value of MODULES in the PAYMENT group.

However, at the point where it's first called, the application cache
isn't ready (loading.app_cache_ready returns False). find_setting is
written so that, if the setting isn't cached and the cache isn't
ready, it just raises SettingNotSet--it doesn't even try to access the
database. This causes it to use the default setting for this value,
which is just the DUMMY payment module.

Later calls to payment_choices return the actual value from the
database, but at that point it's too late: OrderPayment has already
been set up with the wrong value. This is causing a problem with the
Django admin site; specifically, it shows "(None)" for all the order
payments, since they reference payment modules other than "DUMMY".

Can anyone explain why find_setting works this way? Caching is
strictly for performance; the presence or absence of a cache shouldn't
modify the way the software works. I tried to modify find_setting so
it would always access the DB even if the cache weren't ready, but
then the Admin site didn't show a lot of the Satchmo models (including
OrderPayment) on the main page, so I'm presuming there are things in
Satchmo that depend on this behavior.

I can generally reproduce this by killing Apache, then deleting all
the Satchmo cache files, then restarting Apache and accessing the
admin page. The version of Satchmo we're using has some custom
changes (some of which relate to OrderPayment) so it's possible
something we've changed is triggering this.

Any insight regarding this issue is greatly appreciated.

[Bruce Kroeze]

That's an interesting one.  I wrote the caching system, and I'll take a look at this issue.  I feel on first reading that you are correct and that more checks before raising SettingNotSet are reasonable.  Good catch and analysis.

Could you please file a bug on it?  It will help us track changes.

Thanks,

Bruce Kroeze

http://solidsitesolutions.com
Dynamic Designs, Optimized

[CraigH]

I submitted it as ticket #365:
http://www.satchmoproject.com/trac/ticket/365

On May 7, 11:57 am, "Bruce Kroeze" <bkro...@gmail.com> wrote:
> That's an interesting one. I wrote the caching system, and I'll take a look
> at this issue. I feel on first reading that you are correct and that more
> checks before raising SettingNotSet are reasonable. Good catch and
> analysis.
> Could you please file a bug on it? It will help us track changes.
>
> Thanks,

> Bruce Kroezehttp://solidsitesolutions.com