How do I properly clear the Spree Preference cache

[Chris]

I need to know how to properly clear the Spree Preference cache.

I have a multitenant app, and the preferences are getting leaked from
one tenant to the other because the preferences are getting cached
instead of pulling from the db at the beginning of a request.

Ryan? You're the multitenant guru now right. :-) Any ideas?

Thanks,
Chris

[Nate Lowrie]

Chris,

Could you modify the preferences model to store the tenant id with the preference entry?

Regards,

Nate

[Ryan Bigg]

On Mon, Jan 7, 2013 at 11:50 PM, Chris <r3ap3...@gmail.com> wrote:

Ryan?  You're the multitenant guru now right. :-)  Any ideas?

Supposedly :)

Have you considered separating the different store's information into PostgreSQL schemas and then using the Apartment gem to switch between the schemas? As long as the schema search path in PG is set up to only include the "correct" store, then I don't see how it could leak across it.

[Chris]

Nate,
That's exactly what I ended up doing.

Ryan,
Postgres schemas is what I'm using, and they aren't leaking from the
db for that very reason.
The problem is that Spree caches the values in
Spree::Preferences::StoreInstance. So rather than pulling from the DB
again, Spree is pulling whatever value was last cached in memcached.

I got the real problem fixed by overriding the cache settings to add a
tenant id to the key, but I would still like to know how to properly
clear the cache.

The Spree::Preferences::Preferable module has the following code:

if respond_to?(:after_destroy)
after_destroy do |obj|
obj.clear_preferences
end
end

Which would work for any single given model, but I'm not exactly sure
how you would properly execute the clear_preferences method to ensure
that _every_ model that included preferences was cleared.

I would also appreciate it if anyone else knows anywhere else in the
base Spree code that I'm going to run into these kind of caching
issues that I'm not aware of. This one gave me a good scare because
payment method settings get set in the preferences system, which are
getting cached.

Thanks again,
Chris

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

[Ryan Bigg]

Oh, I see. It's coming from the cache and *not* the database.

Well, in that case then you could cheat and use the first part of current DB schema search path as a key prefix for the keys, meaning that they would then be scoped. To do that, I think overriding Spree::Preferences::Preferable's preference_cache_key method would work. Give that a go.