76 | | See attachment:cache_control-r7933.diff |
| 76 | See attachment:cache_control-r7933.diff. |
| 77 | For testing, manual creation of a cache_control table is needed: |
| 78 | {{{ |
| 79 | CREATE TABLE cache_control( key text primary key, generation int); |
| 80 | }}} |
| 81 | |
| 82 | The method names and API has a bit evolved, now I have: |
| 83 | - `env.update_cache_control()`, called in `open_environment` |
| 84 | - `env.invalidate_cache(key)`, called by the Component in place of `config.touch()` |
| 85 | - `env.is_cache_valid(key)`, called by the Component when checking for cache validity |
| 86 | - `env.validate_cache(key)` once the cache has been updated |
| 87 | |
| 88 | That concludes my initial approach to the problem. Now let's take into account what was proposed in idea 1... |
| 89 | |
| 90 | === Discussion === |
| 91 | While the two approaches are quite close in spirit, there are a few differences. |
| 92 | |
| 93 | I initially thought that having the cache control managed at the level of the environment was more natural than having a specialized Component (it's a "service" offered by the environment to all its Components, like providing them with a db connection). |
| 94 | |
| 95 | But I see your point in having the cache logic handled "once for all", without the need to re-implement it in various places. If that's doable in a not too complicated way, it may be worth doing it. |
| 96 | |
| 97 | I've not yet added time-based invalidation, but if really needed, that can be added as well. |
| 98 | |
| 99 | The open problem I see as well is about maintaining a coherent view from the cache during the lifetime of a given request. That might indeed be another argument in favor of a dedicated component with a more advanced cache logic. Anyway, the patch above is at least a first step that seems to work fine in my testing. |