New Cache strategy: Only cache the attributes of AMS

[zlx]

New Cache Strategy: Only cache the attributes of AMS

I think It's better to manage attributes only for AMS.

example:

imagine we have an AMS A, which contain AMS B, which contain AMS C.

If I fetch json from A, 
It will read A's attributes cache + B's result
B's result = B's attributes cache + C's result
C's result = C's attribute cache

therefore, it can manage cache by itself object and reusing the cache as far as possible

If B's cache expired, C's cache and A's cache is still work, it will lead to as little computation as possible

Beside, It will detect the AMS class's change and automatic expired the cache.

[GetContented]

Pretty keen for caching to come back. Also, recursive relationships (Item has_many: items) breaks/broke caching. Should I create a new issue for this? Seems silly when the caching has been taken out.

[zlx]

@JulianLeviston It's so bad for recursive relationships. I never discover this case in my product. Can you give an example in real situation?

[GetContented]

@zlx Not sure what you mean by "it" when you say "it's so bad for recursive relationships".

However, my application has exactly such a recursive relationship... I have a model called Item that has a parent, which is also an Item. (In other words, it's a tree of objects). This is my real application, and it's a real situation. All I want to do is cache a JSON render. I'm not doing any embedding, just caching primary keys. There are no loops... (ie the root parent item is not referred to in any of the subsequent item children) and yet the library loops infinitely for some reason when asked to cache it.

The object trees that I have in my app are probably at most like 10 objects deep in terms of parent/children, and all I want to do is get "all the items", flat, with their referring primary keys (ie their parent_id records).

I'd reckon your PR would address this issue, no?

[zlx]

@JulianLeviston In my understanding, you have situation like below:

A = A's attrs + A1
A1 = A1's attrs + A2
...

An is a A object

for this new cache strategy, I only use cache to replace all the object's attrs, so it will work I think.

But in your situation with so deep relations, I think cache global is more efficiently. consider cache the whole object like use jbuilder to cache AMS or use perforated to cache AMS.

I want to use this PR to make the cache can work efficiently as far as possible when some object changed, because it's the mostly use case I think.

[GetContented]

@zlx I'm not sure. Thanks tho :)

[steveklabnik]

I'm not currently interested in adding huge new features to 0.9, sorry! We will certainly bring caching back in 0.10.