Any movement on this? I just spent the morning banging my head against the
wall trying to figure out why preferences weren't being wiped when I blew
out my dev database. Turns out I had to Rails. cache.clear ... which makes
no sense! Caching preferences???
On Tuesday, March 13, 2012 6:17:35 AM UTC-7, josh jacobs wrote:

Filed an issue: https://github.com/spree/spree/issues/1265


On Mar 13, 2012, at 9:11 AM, Jones Lee wrote:

Good find, I'd really appreciate if you could file a GH issue, it's
definitely something we should look into.

On Tue, Mar 13, 2012 at 11:52 PM, Patrick McElwee <pmce...@gmail.com<javascript:>
wrote:
Thank you! I was beginning to go crazy over this. This is very well
presented.

On Tuesday, September 6, 2011 9:20:54 AM UTC-4, josh jacobs wrote:

I recently resolved an issue with Spree::Config and wanted to post my
results to help the future googler.

*Problem*
Spree::Config values were not predictable. Sometimes they were fine and
returning results as expected, but sometimes they had reverted to the
default values.

*Explanation*
I was able to define a very simple use case that illustrated the
problem. What I discovered was that running any test that invoked
Spree::Config caused the values of Spree::Config preferences in my
development environment to be reset to defaults. The development database
was not changing, but the cached class was.

Even though caching was disabled in test.rb (config.cache_classes =
false), Spree was still caching the configuration because it apparently
disregards this setting. Spree::Config behavior is to loads values first
from the cache if they are available (or at least this is my understanding)
and so running tests updated the cached class and was polluting my
development environment.

*Resolution*
One solution is to add Rails.cache.clear to my tests. This is not DRY.

The better solution was to configure a different cache store for test
and development. In test.rb I added *config.cache_store = :memory_store*,
restarted spork, and everything works.

:)
On Tuesday, September 6, 2011 9:20:54 AM UTC-4, josh jacobs wrote:

I recently resolved an issue with Spree::Config and wanted to post my
results to help the future googler.

*Problem*
Spree::Config values were not predictable. Sometimes they were fine and
returning results as expected, but sometimes they had reverted to the
default values.

*Explanation*
I was able to define a very simple use case that illustrated the
problem. What I discovered was that running any test that invoked
Spree::Config caused the values of Spree::Config preferences in my
development environment to be reset to defaults. The development database
was not changing, but the cached class was.

Even though caching was disabled in test.rb (config.cache_classes =
false), Spree was still caching the configuration because it apparently
disregards this setting. Spree::Config behavior is to loads values first
from the cache if they are available (or at least this is my understanding)
and so running tests updated the cached class and was polluting my
development environment.

*Resolution*
One solution is to add Rails.cache.clear to my tests. This is not DRY.

The better solution was to configure a different cache store for test
and development. In test.rb I added *config.cache_store = :memory_store*,
restarted spork, and everything works.

:)
On Tuesday, September 6, 2011 9:20:54 AM UTC-4, josh jacobs wrote:

I recently resolved an issue with Spree::Config and wanted to post my
results to help the future googler.

*Problem*
Spree::Config values were not predictable. Sometimes they were fine and
returning results as expected, but sometimes they had reverted to the
default values.

*Explanation*
I was able to define a very simple use case that illustrated the
problem. What I discovered was that running any test that invoked
Spree::Config caused the values of Spree::Config preferences in my
development environment to be reset to defaults. The development database
was not changing, but the cached class was.

Even though caching was disabled in test.rb (config.cache_classes =
false), Spree was still caching the configuration because it apparently
disregards this setting. Spree::Config behavior is to loads values first
from the cache if they are available (or at least this is my understanding)
and so running tests updated the cached class and was polluting my
development environment.

*Resolution*
One solution is to add Rails.cache.clear to my tests. This is not DRY.

The better solution was to configure a different cache store for test
and development. In test.rb I added *config.cache_store = :memory_store*,
restarted spork, and everything works.

:)
--
You received this message because you are subscribed to the Google Groups
"Spree" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/spree-user/-/eeI3644iHrAJ.

To post to this group, send email to spree...@googlegroups.com<javascript:>
.
To unsubscribe from this group, send email to
spree-user+...@googlegroups.com <javascript:>.
For more options, visit this group at
http://groups.google.com/group/spree-user?hl=en.

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

--
Don't miss SpreeConf on May 20-21: http://spreeconf.com
Spree is hiring: http://spreecommerce.com/careers

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupspree-user @
categoriesrubyonrails
postedApr 4, '13 at 5:22p
activeApr 4, '13 at 5:22p
posts1
users1
websitespreecommerce.com
irc#RubyOnRails

1 user in discussion

Stefan Wrobel: 1 post

People

Translate

site design / logo © 2022 Grokbase