-
Notifications
You must be signed in to change notification settings - Fork 935
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace ICache interface by a CacheBase class #1777
Replace ICache interface by a CacheBase class #1777
Conversation
This comment has been minimized.
This comment has been minimized.
{ | ||
|
||
public Task<object> GetAsync(object key, CancellationToken cancellationToken) | ||
public override Task<object> GetAsync(object key, CancellationToken cancellationToken) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These overrides are not really needed since the base do the same, but I guess it would be a bit hard for the async generator to detect that case.
/// </para> | ||
/// <para> | ||
/// This base class provides minimal async method implementations delegating their work to their | ||
/// synchronous counterparts. Override them for supplying actual async operations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same pattern as DbConnection
: a default async implementation calling the synchronous methods is provided for relieving implementors of doing that themselves, if their cache has no async operations.
try | ||
{ | ||
impl = settings.CacheProvider.BuildCache(name, properties); | ||
ccs.Cache = settings.CacheProvider.BuildCache(name, properties); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This property setter has no logic, doing the assignment outside of the try
was just complicating the code for no reasons.
try | ||
{ | ||
impl = settings.CacheProvider.BuildCache(name, properties); | ||
ccs.Cache = settings.CacheProvider.BuildCache(name, properties); | ||
} | ||
catch (CacheException e) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway I do not know of any cache implementation throwing this exception... Those from NHibernate-Caches never throw it.
@@ -134,13 +135,17 @@ public partial interface ICacheConcurrencyStrategy | |||
/// </summary> | |||
string RegionName { get; } | |||
|
|||
// 6.0 TODO: type as BaseCache instead | |||
#pragma warning disable 618 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementors will be warned by the ICache
obsolete message about that, but they will not be able to actually prepare for it. I do not see a way to avoid this. The HashtableCacheProvider.BuildCache
implementation pattern commented previously is not usable here, as we may have a cache not deriving from CacheBase
here.
// PreferMultipleGet yields false if !IBatchableCacheConcurrencyStrategy, no GetMany call should be done | ||
// in such case. | ||
return ReflectHelper | ||
.CastOrThrow<IBatchableCacheConcurrencyStrategy>(cache, "batching") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This GetMany
is currently called only in case of lazy batch fetches (using batch-size
). The cases where NHibernate calls GetMany
even if PreferMultipleGet
is false do not use this GetMany
.
var concreteCache = cache.Cache; | ||
if (concreteCache == null) | ||
return null; | ||
return concreteCache as CacheBase ?? new ObsoleteCacheWrapper(concreteCache); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This allows a simplification, by always yielding a CacheBase
provided there is a cache, even if it does not implement itself CacheBase
.
In most cases it will yield the wrapper held by the cache concurrency, avoiding the instantiation here. (The instantiation will occur only if the user uses a custom cache concurrency, which looks very unlikely to me, since the mapping does not allow specifying a custom implementation.)
try | ||
{ | ||
cache.Lock(key); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The finally
is done for unlocking, but there is nothing to unlock if the locking has failed. This line should have been before the try
, even without having the lockValue
to handle. All similar cases have been changed likewise.
/// <exception cref="CacheException"></exception> | ||
bool[] PutMany(CacheKey[] keys, object[] values, long timestamp, object[] versions, IComparer[] versionComparers, | ||
bool[] minimalPuts); | ||
|
||
// 6.0 TODO: remove for using ICacheConcurrencyStrategy.Cache re-typed CacheBase instead | ||
CacheBase CacheBase { get; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can change this interface as it is not yet released.
This property is somewhat obsolete as soon as added. But it should not bother many implementors, since mapping does not allow to specify custom cache concurrency implementations.
bc1aea5
to
e3f6bc9
Compare
This comment has been minimized.
This comment has been minimized.
ab5b465
to
459e840
Compare
Rebased and squashed. |
One note: the |
83 matches for For the cache case, I dislike a bit both patterns indeed. I thought of naming it just |
7331b4f
to
588b121
Compare
7f9ef68
to
e8d9dc6
Compare
Squashed and rebased for resolving conflicts with #1788. |
e8d9dc6
to
2a28975
Compare
2a28975
to
fb0a3ac
Compare
Rebased, and one additional adjustment suggested by @hazzik has been made. As proposed on the development group, and since no continued grounded disagreement has been expressed there since one week after raised concerns being addressed, I intend to merge this PR next week (likely on Wednesday). (I am issuing this notice on PR issued before starting to apply this handling of merges. I will not do it for new PR.) |
In order to ease adding cache features, and provide default implementations for them, use an abstract base class instead of an interface.
This is similar to
DbConnection
,DbCommand
and the like pattern.It allows to reduce the needs for "transitional interfaces" and simplifies implementing new features as it allows to abstract away whether the implementation is obsolete or not, actually supports the new features or not.