You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+9-6Lines changed: 9 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1920,7 +1920,7 @@ end
1920
1920
Then, on each Resource you want to cache, call the `caching`method:
1921
1921
1922
1922
```ruby
1923
-
class PostResource << JSONAPI::Resource
1923
+
class PostResource < JSONAPI::Resource
1924
1924
caching
1925
1925
end
1926
1926
```
@@ -1933,7 +1933,8 @@ The default Rails timestamps handle this pretty well, and the default cache key
1933
1933
You can use an alternate field (which you are then responsible for updating) by calling the `cache_field` method:
1934
1934
1935
1935
```ruby
1936
-
class PostResource << JSONAPI::Resource
1936
+
class PostResource < JSONAPI::Resource
1937
+
caching
1937
1938
cache_field :change_counter
1938
1939
1939
1940
before_save do
@@ -1951,10 +1952,12 @@ end
1951
1952
```
1952
1953
1953
1954
If context affects the content of the serialized result, you must define a class method `attribute_caching_context` on that Resource, which should return a different value for contexts that produce different results. In particular, if the `meta` or `fetchable_fields` methods, or any method providing the actual content of an attribute, changes depending on context, then you must provide `attribute_caching_context`. The actual value it
1954
-
returns isn't important, except that the value must be different if any relevant aspect of the context is different.
1955
+
returns isn't important, what matters is that the value must be different if any relevant part of the context is different.
1955
1956
1956
1957
```ruby
1957
-
class PostResource << JSONAPI::Resource
1958
+
class PostResource < JSONAPI::Resource
1959
+
caching
1960
+
1958
1961
attributes :title, :body, :secret_field
1959
1962
1960
1963
def fetchable_fields
@@ -1984,14 +1987,14 @@ end
1984
1987
*Modelsfor cached Resources must update a cache key field whenever their data changes. However, if you bypass Railsand e.g. alter the database row directly without changing the `updated_at` field, the cached entry for that resource will be inaccurate. Also, `updated_at` provides a narrow race condition window; if a resource is updated twice in the same second, it's possible that only the first update will be cached. If you're concerned about this, you will need to find a way to make sure your models' cache fields change on every update, e.g. by using a unique random value or a monotonic clock.
1985
1988
* If an attribute's value is affected by related resources, e.g. the `spoken_languages` example above, then changes to the related resource must also touch the cache field on the resource that uses it. The`belongs_to` relation inActiveRecord provides a `:touch` option for this purpose.
1986
1989
*JR does not actively clean the cache, so you must use an ActiveSupport cache that automatically expires old entries, or you will leak resources. TheMemoryCache built in to Rails does this by default, but other caches will have to be configured with an `:expires_in` option and/or a cache-specific clearing mechanism.
1987
-
*Similarly, if you make a substantial code change that affects a lot of serialized representations (i.e. changing the way an attribute is shown), you'll have to clear out all relevant cache entries yourself. You do not have to do this after merely adding or removing attributes; only changes that affect the actual content of attributes require manual cache clearing. The simplest way to do this is to run `JSONAPI.configuration.resource_cache.clear` from the console.
1990
+
*Similarly, if you make a substantial code change that affects a lot of serialized representations (i.e. changing the way an attribute is shown), you'll have to clear out all relevant cache entries yourself. The simplest way to do this is to run `JSONAPI.configuration.resource_cache.clear` from the console. You do not have to do this after merely adding or removing attributes; only changes that affect the actual content of attributes require manual cache clearing.
1988
1991
* If resource caching is enabled at all, then custom relationship methods on any resource might not always be used, even resources that are not cached. For example, if you manually define a `comments` method or `records_for_comments` method on a Resource that `has_many :comments`, you cannot expect it to be used when caching is enabled, even if you never call `caching` on that particular Resource. Instead, you should use relationship name lambdas.
1989
1992
* The above also applies to custom `find` or `find_by_key` methods. Instead, if you are using resource caching anywhere in your app, try overriding the `find_records` method to return an appropriate `ActiveRecord::Relation`.
1990
1993
* Caching relies on ActiveRecord features; you cannot enable caching on resources based on non-AR models, e.g. PORO objects or singleton resources.
1991
1994
* If you write a custom `ResourceSerializer` which takes new options, then you must define `config_description` to include those options if they might impact the serialized value:
0 commit comments