No Expiration Mode

Version 1.6.5 introduces a new configuration flag that allows you to disable automatic default expiration when absoluteExpiration is not provided.

This update gives you full control over TTL behavior while remaining 100% backward compatible.

---

🧠 Default Expiration Behavior

Previous Behavior (Still Default)

If you called:

await cache.SetAsync("key", value);

And did not provide absoluteExpiration, the cache service would automatically apply a default expiration (12 hours by default).

This behavior is preserved.

---

🆕 New Configuration Flag

You can now control this behavior using:

UseDefaultAbsoluteExpirationWhenNull

This flag determines whether the default TTL should be applied when no expiration is explicitly provided.

• true (default): apply default TTL (old behavior)

• false: do not apply TTL automatically (persistent keys in Redis / no auto-expiration behavior)

---

⚙️ Configuration (appsettings.json)

{
  "CacheConfiguration": {
    "UseDefaultAbsoluteExpirationWhenNull": true,
    "RedisConfiguration": {
      "TimeConfiguration": {
        "AbsoluteExpirationInHours": 12
      }
    },
    "InMemoryConfiguration": {
      "TimeConfiguration": {
        "AbsoluteExpirationInHours": 12,
        "SlidingExpirationInMinutes": 30
      }
    }
  }
}

---

🔍 Behavior Matrix

UseDefaultAbsoluteExpirationWhenNull	absoluteExpiration provided?	Resulting TTL
true (default)	✅ Yes	Uses the provided TTL
true (default)	❌ No	Uses default TTL (e.g., 12 hours)
false	✅ Yes	Uses the provided TTL
false	❌ No	No TTL is applied automatically

Notes:

• In Redis, this means the key can become persistent (no expiration).

• In InMemory, behavior depends on the underlying cache entry options (but the library will not force a default absolute TTL when this flag is false).

---

🛡 Backward Compatibility

If you do nothing, your system behaves exactly like previous versions.

public bool UseDefaultAbsoluteExpirationWhenNull { get; set; } = true;

✅ Default is true, meaning:

• ✔ No breaking changes

• ✔ No migration required

• ✔ Existing applications continue working as-is

---

🧩 Why This Was Added

Some use cases require:

• Long-lived cache entries

• Persistent Redis keys

• Manual expiration control

• Hybrid TTL strategies

• External expiration management

Previously, the default TTL was always applied when absoluteExpiration was missing. Now you have full control.

---

🧪 Usage Examples

Default Behavior (Recommended for most apps)

await cache.SetAsync("key", value);

➡ Stored with default expiration (e.g., 12 hours)

Persistent Key (No Expiration)

"UseDefaultAbsoluteExpirationWhenNull": false

await cache.SetAsync("key", value);

➡ Stored without expiration (Redis key becomes persistent)

---

🔄 Applies To

The new flag affects both providers:

• RENRedisCacheService

• RENInMemoryCacheService

Both providers respect the same configuration behavior.

---

🧱 New DI Registration Overload (Configuration-Based)

Version 1.6.5 also introduces a configuration-based registration overload.

Instead of manually configuring options, you can now do:

builder.Services.AddRENCaching(
    builder.Configuration,
    CacheType.Redis,
    multiplexerProvider,
    RedisMultiplexerLifetime.Singleton,
    CacheServiceLifetime.Singleton);

Or with custom interface + implementation:

builder.Services.AddRENCaching<ICacheService, CacheService>(
    builder.Configuration,
    CacheType.Redis,
    multiplexerProvider,
    RedisMultiplexerLifetime.Singleton,
    CacheServiceLifetime.Singleton);

✅ This automatically binds:

• "CacheConfiguration"

into:

• RENCacheKitOptions

So no manual Configure<RENCacheKitOptions>() is required.

---

🧩 Custom Cache Services (Important)

If you provide your own cache service implementation (e.g. deriving from the base services), make sure your constructor accepts and forwards the options so the configuration is actually applied.

✅ Redis (custom implementation)

public sealed class MyRedisCacheService : RENRedisCacheService
{
    public MyRedisCacheService(
        IConnectionMultiplexer connection,
        IOptions<RENCacheKitOptions> options)
        : base(connection, options) // ✅ forwards options to base
    {
    }
}

✅ InMemory (custom implementation)

public sealed class MyInMemoryCacheService : RENInMemoryCacheService
{
    public MyInMemoryCacheService(
        IMemoryCache cache,
        IOptions<RENCacheKitOptions> options)
        : base(cache, options) // ✅ forwards options to base
    {
    }
}

If you don’t take/forward IOptions<RENCacheKitOptions>, the base services may fall back to defaults, and your UseDefaultAbsoluteExpirationWhenNull setting won’t have any effect.

---

📌 Recommended Usage

Keep UseDefaultAbsoluteExpirationWhenNull = true unless:

• You intentionally want persistent keys

• You manage TTL manually

• You need strict expiration policy control

• You operate with hybrid expiration models

---

🚀 Summary

Version 1.6.5 introduces:

• Optional persistent key support (when expiration is omitted)

• Full TTL control via UseDefaultAbsoluteExpirationWhenNull

• Zero breaking changes (default behavior preserved)

• Configuration-based DI overload

• Unified behavior across Redis & InMemory providers