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
I think it's better to implement caching as a dedicated feature instead of composing a DataSource.
Once the oplog and a tailable cursor has been implemented, it's pretty easy to add a long-lived memory cache which would be an atom referencing a map of $resource-$id keys to document futures.
This way requests are de-deduplicated de facto.
In the case of querying several ids at one time, every id can point to a future extracted from the multi-id running future.
A good simplification IMO:
when a query is made against ids directly, use the cache directly when possible (otherwise feed it with results).
when a query is made using a find specification, get the ordered ids from that query using the datasource directly, and then fetch the corresponding documents from the cache if they exists, else feed it.
The text was updated successfully, but these errors were encountered:
I think it's better to implement caching as a dedicated feature instead of composing a DataSource.
Once the oplog and a tailable cursor has been implemented, it's pretty easy to add a long-lived memory cache which would be an atom referencing a map of $resource-$id keys to document futures.
This way requests are de-deduplicated de facto.
In the case of querying several ids at one time, every id can point to a future extracted from the multi-id running future.
A good simplification IMO:
The text was updated successfully, but these errors were encountered: