# Can't models be cached in development env?

**URL:** <https://www.ruby-forum.com/t/cant-models-be-cached-in-development-env/141263>\
**Category:** Rails\
**Created:** [June 24, 2008, 5:22am UTC](https://www.ruby-forum.com/t/cant-models-be-cached-in-development-env/141263 "2008-06-24T05:22:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ppjunty](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/aeb1de/32.png) [@ppjunty](https://www.ruby-forum.com/u/ppjunty)\
**Post date:** [June 24, 2008, 5:22am UTC](https://www.ruby-forum.com/t/cant-models-be-cached-in-development-env/141263/1 "2008-06-24T05:22:04Z")

</div>

i’m caching constant models in memory, but if  
i try something like

@user.type = Rails.cache.read ‘types/1’

i get:

“ActiveRecord::AssociationTypeMismatch - Type(#39040660)  
expected, got Type(#29355550)”

the class is the same, but the ids aren’t, so rails  
refuse the association. but if i enable class\_cache,  
like in production, everything goes well. so here  
is the question: is there a way to work with this  
kind of caching in development mode? thanks.

ps: there is a thread with a similar problem  
at ‘[AssociationTypeMismatch: RoleType expected, got RoleType - Rails - Ruby-Forum](http://www.ruby-forum.com/topic/101817)’ but  
their solution is not working for this rails  
version.

---

<div class="post-metadata">

**Author:** ![ppjunty](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/aeb1de/32.png) [@ppjunty](https://www.ruby-forum.com/u/ppjunty)\
**Post date:** [June 24, 2008, 11:13am UTC](https://www.ruby-forum.com/t/cant-models-be-cached-in-development-env/141263/2 "2008-06-24T11:13:55Z")

</div>

On Jun 24, 4:22 am, Pepe J. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> the class is the same, but the ids aren’t, so rails  
> refuse the association. but if i enable class\_cache,  
> like in production, everything goes well. so here  
> is the question: is there a way to work with this  
> kind of caching in development mode? thanks.

Not really. The problem is that after each request rails tears down  
the classes it has loaded and guts them (and then unsets the  
corresponding constant), so your cached object is of a class with no  
methods etc… and distinct from the current Type class.

Fred

---

<div class="post-metadata">

**Author:** ![ppjunty](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/aeb1de/32.png) [@ppjunty](https://www.ruby-forum.com/u/ppjunty)\
**Post date:** [June 24, 2008, 10:04pm UTC](https://www.ruby-forum.com/t/cant-models-be-cached-in-development-env/141263/3 "2008-06-24T22:04:32Z")

</div>

thanks for your answer, Fred. it’s really a pain, do you know the  
reason for that? wouldn’t a simple class check be enough,  
like in java?

> Not really. The problem is that after each request rails tears down  
> the classes it has loaded and guts them (and then unsets the  
> corresponding constant), so your cached object is of a class with no  
> methods etc… and distinct from the current Type class.
> 
> Fred

---

<div class="post-metadata">

**Author:** ![ppjunty](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/aeb1de/32.png) [@ppjunty](https://www.ruby-forum.com/u/ppjunty)\
**Post date:** [June 24, 2008, 11:30pm UTC](https://www.ruby-forum.com/t/cant-models-be-cached-in-development-env/141263/4 "2008-06-24T23:30:57Z")

</div>

On Jun 24, 9:04 pm, Pepe J. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> thanks for your answer, Fred. it’s really a pain, do you know the  
> reason for that? wouldn’t a simple class check be enough,  
> like in java?

The problem is that technically the two classes really are different.  
The convenience of the automatic reloading does have some drawbacks.  
If you can get your cache to be wiped at the end of the request cycle  
(see config.to\_prepare etc…, or mark the code handling the cache as  
reloadable) then you would also be ok (but your cache would  
effectively be wiped for each request).

Fred
