CacheItemVersion has internal Constructors

[hype8912]

The CacheItemVersion has internal constructors making it impossible for developers to store the item version value without either making a dependency on NCache CacheItemVersion object or storing the value as an object and then casting it back to a CacheItemVersion when needed. Please make the constructors public or I would be happy to make a merge request for the change.

[Kal-Alachisoft]

Hi @hype8912 ,

Let me discuss on this with the team here and I will get back to you.

Kal Ali NCache Team

[Kal-Alachisoft]

Hi @hype8912

CacheItemVerson is an internal class therefore its constructor is also internal, its properties are used in class as read-only. Server is responsible for assigning values to Version property of CacheItemVersion class based upon incremental number whenever there is an update call to the Cache. User or client can only use CacheItemVersion class as an observer (read only).

The reason for keeping it this way is because the logic within the code is in such a way that it reads values that it has created itself in an incremental fashion. If a user updates it to something that may not be compatible with when NCache Server tries to read and work the value.

Please give us details as to why you require this so that I can help you better regarding this.

Kal Ali NCache Team

[hype8912]

In the code linked it shows the class as public "public class CacheItemVersion : IComparable". The only thing internal in that class is the constructors.

In development, we try to keep our implementation of a specific product isolated to a section of code so that we abstract our actual implementation encase we need to change it in the future. So for a cache implementation, I may have my own class that does the implementation of NCache that implements and exposes an ICache interface. The rest of my application will then have a dependency on ICache and not a direct implementation on NCache. I may then have an object called CacheEntry that implements properties like key, value, version, callbacks, expirations. This is so I'm not dependent on a specific cache implementation. The version in NCache is just a number. ULong to be exact. The ability to store a built-in type of ULong and not a CacheItemVersion allows a developer to not be fully dependent on the NCache. Right now we get around this by storing the CacheItemVersion as an object and then casting it back to a CacheItemVersion in the implementation but that really isn't needed if we could create a new CacheItemVersion class by passing in a ULong value.

The point I'm getting at is the only thing marked internal is the constructor which prevents creating an instance of the class. It doesn't prevent changing the Version value.

[Mark-NCache]

We've had a discussion with our engineering team about this, The reason we have kept the constructor of CacheItemVersion class private is because a unique version is assigned by the server to items in the cache and it is intentional so that version is always set by NCache on server side and not on the client side.

If the constructor is made public then there could be number of issues and one example could be that two threads might assign same cache item version to two separate cache items if it is done on the client side. Engineering plans to keep this private to ensure consistent version management behavior.