Problem/Motivation

Additionally to the usage of the entity cache it would be handy to have a lower level request / query cache.
Especially because filter / listing query to endpoints that always return the full entity data do not massively benefit from the entity cache.

Steps to reproduce

Proposed resolution

Add a cache handling to the RestClient::countQuerySource() and RestClient::querySource().
Use tags to mark cache items, flush appropriate tag on external entity config save.

Remaining tasks

  1. Write code
  2. Write tests
  3. Review

User interface changes

New option to defined query cache lifetime in the storage config form.

API changes

None.

Data model changes

None.

Issue fork external_entities-3511947

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

das-peter created an issue. See original summary.

das-peter opened merge request !78

guignonv’s picture

guignonv
Primary language French
Location Montpellier
commented

Any update on this?

das-peter’s picture

das-peter commented

Any update on this?

We've been using this for a while now and it looked good.
I just did a rebase so it applies to the latest 3.0.x - but I'm not 100% I caught all changes.
Will review again and try to provide feedback asap.

guignonv’s picture

guignonv
Primary language French
Location Montpellier
commented
Status: Active » Postponed

I reviewed the code again and I am not a big fan of so many API changes (REST constructor, querySource() and countQuerySource() signatures changed). Also, there are no associated tests to see what those features bring in practice. And the REST code evolved and there are now conflicts to solve. I fear unexpected side effects hard to debug. To be honest, I am quite reluctant to add those changes to 3.0.0. Including those changes may delay too much a release. Too risky for me.

What I propose you is to write a new REST client ("AdvancedCacheRestClient" for instance?) that overrides the current one (or the JSON::API one if you use it). Use the current REST client implementation, tag somewhere the corresponding commit so we can compare your changes with the original version in the future, and port your "cache" changes to that new client. And once we got a 3.0.0 released, we could reconsider to port your changes to a 3.1.0 version (API changes --> new version).