Class Macros & Inheritance

[tstone]

Background

This PR changes how the class macros (force_cache_class and cache_version) interact with inheritance.

Consider the following scenarios. What would the correct cache prefix be?

Case 1:

class Foo
  include AtomicCache::GlobalLMTCacheConcern
  cache_version(6)
end
class Bar < Foo
  force_cache_class('asdf')
end

Case 2:

class Foo
  include AtomicCache::GlobalLMTCacheConcern
  force_cache_class('asdf')
end
class Bar < Foo
  cache_version(6)
end

This PR changes is so that the preference of values is: Local override > Parent override > default value. Previously the gem would not consider parent override values. Summarized below as...

BEFORE:
Case 1 = asdf
Case 2 = bar:v6

AFTER:
Case 1 = asdf:v6
Case 2 = asdf:v6

Version

This change will not break the interface of existing code, but could possibly be considered backwards incompatible due to the key changing (assuming something relies on knowing what that value is). Since the gem is still in pre-release/pre-1.0 status though a minor version change will be used.

Tasks

• Code of Conduct reviewed
• Specs written and passing
• Backwards-incompatible changes called out in this PR
• Increment the version file (./lib/atomic_cache/version.rb) when applicable
  • See semver.org for what segment to increment

[lebeerman]

🔥 This is a great write up.

[lebeerman]

if no force_cache_class is used would the expectation be foo7:v6:lmt?

[tstone]

if the force_cache_class on line 157 was absent, it would be the same. If the force_cache_class on line 160 was absent, it would be foo:v6:lmt, because it prefers explicit overrides on the parent ahead of default values on the class.

[lebeerman]

Thanks, makes sense. Also, saw the notes in the new docs that both force methods should work in a similar way wrt inheritance.

[lebeerman]

😎 The improvement to the docs are awesome.