Uncommitted data can be written to cache when mixing cached and non-cached models

[betamatt]

The model that begins a transaction determines whether cache-safe transaction semantics are used. If safe and unsafe transactions are nested, data can end up committed to cache even when the database transaction rolls back.

It's important to continue supporting use cases where only some models are cached but I feel a refactor is needed to move transaction wrappers to the AR::Base level. If model caching is used at all then all transactions should be wrapped with cache-safe semantics, not just models marked is_cached. This change implies that a cache repository needs to be configured at the AR::Base level as well, and not just on individual models, although it can be overridden on a per-model basis.

I'm opening this issue for discussion prior to putting together a patch.

[ashleym1972]

Sigh. I knew that having some classes cached and others un-cached would be a problem.

I don't see an issue with including the cache-safe code to each model and using a flag to determine if the model is cached or not during the transaction. It'll be a pain to change that much code, however.

[betamatt]

Yeah, it will be. I'm trying to find time to patch this. I've just fixed each individual case where it causes a problem but I'm sure there's some sleepers waiting to bite me.