(possible) cache_sources + versioncake problem

[alepore]

Hi, i noticed a strange behaviour using cache_sources = true (no other options set) and versioncake, not sure if it's a bug or i don't understand the cache_sources option.

example: update.rabl is like:

object @order
extends "orders/show"

and i have show.v2.rabl and show.v3.rabl

if i call the update action with api_version=2 it includes the show.v2.rabl template. if then i call update with api_version=3 it still load the show.v2.rabl template and not the v3 because of the caching. with cache_sources = false it loads the correct template every time.

Is that the right behavior or it should cache different sources for every template version?

[nesquena]

Ideally it would cache different versions automatically. Sounds like this is a case of a limitation of the caching system. Just curious if you try 0.9.0.pre2 do you experience the same issue?

[alepore]

Yes, same behavior with 0.9.0.pre2

[nesquena]

I see OK, I think I know what the issue is. What version of Rails are you using?

[alepore]

rails 3.2.12, versioncake 1.2.0. this also happens in development (with rails defaults for this environment)

[nesquena]

@databyte @siong1987 any ideas on the best way to fix this? appreciate any help on the caching stuff.

[sssionggg]

If cache_sources is set to true, rabl will cache the lookup for the view template files. But, it doesn't seem to work with versioncake.

We can close this issue unless we want to make rabl compatible with versioncake.

[bwillis]

I was just looking into a RABL/versioncake issue on my side and came across this.

Taking a quick look through the caching code, it looks like source cache key only considers the name of the file. Versioncake integrates into the ActionView::LookupContext registered details which includes locale, format, etc.

In order to support caching templates with different details (orders/show.v2.rabl or orders/show.es.rabl), I think it would require using the ActionView::LookupContext#details_key within the source cache key when looking up a Rails template.

[nesquena]

Thanks Ben, I think you are absolutely right. And it does seem like it would be a nice addition for us to include the lookup context details in the cache key. What do you think @siong1987 @databyte ?

[sssionggg]

that will mean that we will have to drop support for non-rails frameworks.

@bwillis thanks! that indicator will help a lot. i was just going to look into the code of versioncake.

[nesquena]

I definitely wouldn't want to drop support for sinatra and padrino (where I primarily use rabl myself), more likely we should just ignore that type of stuff outside of a rails context.

[sssionggg]

okay. we can do a check as usual then. let me look into it.

[RepublicOfAppsLLC]

Hi,

Any progress @siong1987 or @nesquena ?

This is an issue for us - when we push a new template.vN+1.json.rabl, rabl continues to serve the old template.vN.json.rabl. To clear the cache we have to do Rails.cache.clear which seems heavy-handed.

We are also using versioncake and many people I know using rabl are also using versioncake or similar for api versioning.

Is there any way we can fix this in rabl, so that when a new version gets deployed, rabl doesn't continue to serve the old incorrect version? :-)

I'm happy to take a look if somebody can give me some pointers.

Thanks!

[sssionggg]

@RepublicOfAppsLLC i just looked into it again. whatever versioncake is doing is definitely not standard. check out this file here: https://github.com/bwillis/versioncake/blob/4a5d2cdacfa8fcaabc50993333d27572c2ecef70/lib/versioncake/view_additions.rb#L26

if you really want to hack this out, check it here: https://github.com/nesquena/rabl/blob/2826ce5803bd206c3410625d9d63701b5fae03d6/lib/rabl/partials.rb#L77

the last parameter {:formats => [source_format]} might need to take in more arguments, for example, versions for the versioncake gem.

or, we can recreate a better version of fetch_rails_source.