multi_fetch_fragments #379

Closed
kidpollo opened this Issue Dec 20, 2012 · 7 comments

Projects

None yet

4 participants

@kidpollo

If I have an index action with multiple fragments, does rabl support multi_fetch_fragments https://github.com/n8/multi_fetch_fragments or is there a way I can use read_multi to speed things up?

@databyte
Collaborator

An index with multiple collections will be cached under the entire collection. Not as individual caches for each individual item. You should test it out to see if it works the way you intend it to.

@kidpollo

I am talking about an index with a single collection. The use case is pretty common. Say you have and endpoint that renders a list of topics. Each topic resourse can be cached independently reducing the time it takes to render each partial.

This way you avoid dealing with caching the complete index action which most of the times does not make sense to cache on api's with multiple sorting and filtering mechanisms, that would be a waste.

@databyte
Collaborator

Agreed. But throwing in a gem that adds that support to Rails won't do a thing for Rabl. You'll need to write up something specific for Rabl. I can't say I'll be able to add that support any time soon but I'd be more than happy to review a pull request.

@ahlatimer
Contributor

Here's a really rough pass of this: ahlatimer@95875ee

Currently only supports read_multi via a single extends. Also breaks about half of the tests, but it seemed to work in the app that I need this support in.

The problems I'm encountering are that rabl tends to be somewhat aggressive about converting things to a hash, and there is no easy communication between a partial and its parent view. The latter is a sound design decision in general, but it makes this a bit of a bear.

I get the feeling that this will likely require a more extensive change to the way rabl renders than I had initially hoped. I'd like to get this merged upstream at some point, rather than maintaining my own fork of rabl. If you happen to have any advice on how best to design these changes, I'd appreciate it.

@ahlatimer
Contributor

I made a second pass at it. This breaks significantly fewer things (only 3 tests failing at the moment), but is a bit more wide-reaching. It changes the way render is called by first requiring that apply (functionally does everything render did, but without calling to_#{format}) happens before it. By allowing just apply to be called, we can figure out what all of the cache directives are, allowing us to generate cache keys that can be fetched using read_multi.

ahlatimer@f8ebbb6

@nesquena
Owner
nesquena commented Mar 5, 2013

Really interesting changes here, need to sit down and review them soon. Thanks for taking the time to make this work.

@ahlatimer
Contributor

No problem. I'd love to hear any feedback you might have. I only sat down with the source a few days ago, so I wouldn't be surprised if there's a way of implementing this that's more cohesive with the code that's already there.

@nesquena nesquena closed this in #585 Oct 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment