[MGNLCACHE-87] Allow to customize cache entries / cache store Created: 19/Feb/15  Updated: 25/Feb/15  Resolved: 20/Feb/15

Status: Closed
Project: Cache Modules
Component/s: None
Affects Version/s: None
Fix Version/s: 5.4

Type: Improvement Priority: Neutral
Reporter: Roman Kovařík Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLPN-201 Allow to cache variants Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   
  • pass cache policy result Store#makeCachedEntry
  • extract delegate cache entry from uncacheable entry


 Comments   
Comment by Jan Haderka [ 20/Feb/15 ]

DelegateCacheEntry

  • Doesn't look like not simple delegate to me. It's really guarding the entry making sure it can be executed only once so it's more like SingleReplayCacheEntryWrapper or ReplayOneTimeOnlyCacheEntryWrapper or something like that no?
  • also the transient variable use there is bit out of place. Transients are nullified only during serialization. Why do you need to have it nullified after being persisted to disk and loaded back (ignoring the fact that ehCache 2.9 doesn't offer disk persistence in CE version)?

Store

   /**
	     * @deprecated since 5.4. Use {@link info.magnolia.module.cache.CachePolicy#getTtlVoters()} instead.
	     */
	    @Deprecated
	    public boolean isCacheable(CachedEntry cacheEntry, Cache cache) {
	        DeprecationUtil.isDeprecated("Returning false. Use info.magnolia.module.cache.CachePolicy#getTtlVoters() instead.");
	        return false;	
  • I find this bit of deprecation (and there's more in the class then one i copied above) bit troublesome. While we are keeping public API unchanged so code doesn't fail to compile, it will still not work as expected and it would be harder for anyone having their own executor based on Store to figure out that their code is broken. Isn't it better in such cases to break the contract and make their code fail already at compile time so they know earlier? Or invest extra effort to make code still work correctly for extenders (if possible at all).
Comment by Roman Kovařík [ 20/Feb/15 ]
Generated at Sun Feb 11 23:52:04 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.