I'm finally getting back to you. . .

I had to hunt a bit but the items about caching configuration is here:
http://www.satchmoproject.com/docs/dev/settings.html

if you search for "CACHE_BACKEND" you will find see it.

CACHE_BACKEND is an old-style configuration. When I did that (with
Memcache) I found that the pages, etc. weren't cached. I then looked at
Django's Caching How-to docs and found that caching for Django 1.3 is not
done like that anymore.

My $0.02 -- if you are still on tip, it probably still applies.

On Thu, Nov 8, 2012 at 9:04 AM, Paul Walsh <paulywa...@gmail.com> wrote:

> Thanks Mike, this is helping a great deal.
>
> Seeing as caches like Memcached, Redis, are systems that by design can
> lose data, in preference for speed, using this for CC details is to me a
> very strange design decision, and I sure wish I knew about that via the
> documentation.
>
> I don't mind using a DB cache (I am currently still using DB cache for
> SORL on this site too), so I will set up a db cache anyway. The site is on
> the production machine, but is not exposed to real trafic yet, so I am
> still actually using locmem for cache.
>
> And again - the thing with the old style and new style cache declarations
> - is that in the docs? I'd love to know that I just missed it somehow... I
> am using latest django and Satchmo tip - do you know if this still applies?
>
> *Paul Walsh*
> 0543551144
>
>
>
> On Thu, Nov 8, 2012 at 4:57 PM, Mike Hostetler 
> <m...@squarepegsystems.com>wrote:
>
>> I found the cache requirement in the code -- I was debugging why we were
>> getting an occasional stopped transaction (transactions were saved as
>> LINKED) and discovered that it how it worked. This was a problem with
>> Memcache -- Memcache was working but once in a while I would have a cache
>> miss on the credit card number, which is a bad thing. When I switched to
>> the database cache, the problem with the LINKED transactions all but went
>> away (now it happens when a user reloads a page when Satchmo is waiting for
>> response to their external service request, al a AuthorizeNet or UPS).
>>
>> Cache invalidation is always a tricky subject -- I kinda had the same
>> problem. Did you try anything else but Memcache? I didn't look at any other
>> caching except Database and Memcache (since they are well-documented and
>> come standard with Django). I'm certain that someone has developed plugins
>> for others.
>>
>> For Satchmo:  you do have to setup the cache twice: once for Django using
>> the 'CACHES' dictionary and another time with the 'old' way with
>> CACHE_BACKEND,CACHE_MIDDLEWARE_SECONDS. and CACHE_MIDDLEWARE_KEY_PREFIX.
>> That last one is how Satchmo uses the cache for cc numbers, etc.
>>
>>
>> On Thu, Nov 8, 2012 at 8:40 AM, Paul Walsh <paulywa...@gmail.com> wrote:
>>
>>> Thanks Mike,
>>>
>>> Where did you find this information about the credit card info + cache?
>>> For the life of me, I can't find anything in the docs about this.
>>>
>>> I am not feeling the love for the Satchmo docs for a bunch of reasons
>>> right now.... but anyway, I digress.
>>>
>>> It is not that I don't want to use caching in production. I have a
>>> problem where the cache doesn't seem to be invalidating in some cases, and
>>> I am therefore diving in to Satchmo's caching and just trying to understand
>>> what is going on (particularly, how it is different from Django's built in
>>> caching, or not).
>>>
>>> So, my first step was to work out how to turn caching off...
>>>
>>> Also, is it possible to use Johnny Cache with Satchmo? Or, a Redis cache?
>>>
>>> I am also wondering, concerned, why could you get a memached backend
>>> working with Satchmo? This is fairly trivial to setup with Django projects
>>> usually.
>>>
>>> thanks.
>>>
>>> *Paul Walsh*
>>> 0543551144
>>>
>>>
>>>
>>> On Thu, Nov 8, 2012 at 4:15 PM, Mike Hostetler <
>>> m...@squarepegsystems.com> wrote:
>>>
>>>> I'm surprised no one answered this. I'll take a shot . .
>>>>
>>>> You can't. Or you can, but then you can't sent credit card info to the
>>>> payment processor. One of the decisions made in Satchmo was to use the
>>>> cache to persist the credit card number from one screen to the next. I'm
>>>> not going to express my opinion on that decision . . .
>>>>
>>>> But why don't you want to use caching in production? That really
>>>> doesn't make a lot of sense -- a properly configured caching system is
>>>> worth the time in any Django app. I did have some problems with Memcache so
>>>> I switched it to a database cache and that has helped a lot (YMMV with
>>>> Memcache -- I actually would rather use that than the database cache).
>>>>
>>>>
>>>>
>>>> On Nov 7, 2012 10:14 AM, "Paul Walsh" <paulywa...@gmail.com> wrote:
>>>>
>>>>> I want to disable caching in Satchmo, in production.
>>>>>
>>>>> I can't find anything in the docs that explicitly declares how I can
>>>>> managing Satchmo's caching.
>>>>>
>>>>> I'd love a pointer to the right place in the docs, if there is one,
>>>>> and also if anyone know hows I can disable caching.
>>>>>
>>>>>
>>>>>  --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Satchmo users" group.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msg/satchmo-users/-/S2MNqFXmnPkJ.
>>>>> To post to this group, send email to satchmo-users@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> satchmo-users+unsubscr...@googlegroups.com.
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/satchmo-users?hl=en.
>>>>>
>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Satchmo users" group.
>>>> To post to this group, send email to satchmo-users@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> satchmo-users+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/satchmo-users?hl=en.
>>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Satchmo users" group.
>>> To post to this group, send email to satchmo-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> satchmo-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/satchmo-users?hl=en.
>>>
>>
>>
>>
>> --
>> Mike Hostetler
>> SquarePeg Systems
>> http://www.squarepegsystems.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Satchmo users" group.
>> To post to this group, send email to satchmo-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> satchmo-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/satchmo-users?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Satchmo users" group.
> To post to this group, send email to satchmo-users@googlegroups.com.
> To unsubscribe from this group, send email to
> satchmo-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/satchmo-users?hl=en.
>



-- 
Mike Hostetler
SquarePeg Systems
http://www.squarepegsystems.com

-- 
You received this message because you are subscribed to the Google Groups 
"Satchmo users" group.
To post to this group, send email to satchmo-users@googlegroups.com.
To unsubscribe from this group, send email to 
satchmo-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/satchmo-users?hl=en.

Reply via email to