mirror of https://github.com/hanzokv/go.git synced 2026-09-24 00:31:51 +00:00

Files

T

zeekay 6994cf05aa kv, not redis: rename the package, the extras and the URL scheme

We do not use Redis. The client was a go-redis fork and still said so
everywhere: `package redis`, `redis.NewClient`, `redis://`, `extra/redisotel`.
Consumers wrote `redis.Client` against a Valkey-backed store called KV.

  package redis            -> package kv          (93 decls)
  redis.X                  -> kv.X                (2,794 call sites)
  "redis: …" errors        -> "kv: …"             (206)
  extra/redis{otel,cmd,prometheus,census} -> extra/kv{otel,cmd,prometheus,census}
  redis:// , rediss://     -> kv:// , kvs://      (ParseURL)
  Redis*/‌*Redis* idents    -> KV*/*KV*
  REDIS_VERSION, REDIS_ENDPOINTS_CONFIG_PATH -> KV_*

I previously argued this rename was unsafe because much of it was "wire
contract". That was wrong, and the categorisation shows why: RESP command names
are GET/SET/HSET — they never contain the word. Of 5,771 occurrences only two
kinds were server-visible at all: the ParseURL scheme (we choose what we pass;
our configs already use kv://) and the CLIENT SETINFO lib-name label, which the
server merely records. Nothing here changes a byte of protocol.

Two things deliberately keep the old spelling:
  RediSearch  — names a specific external module the FT.* commands map to.
  StoreDist   — contains the letters by accident (sto-reDis-t), not the word.

Breaking for consumers by design: every import site must move redis.X -> kv.X.
Minor bump, never a major — this module stays v9 forever.

2026-07-26 08:34:19 -07:00

3.8 KiB

Raw Permalink Blame History

Disable Maintenance Notifications Example

This example demonstrates how to use the go-kv client with maintenance notifications disabled.

What are Maintenance Notifications?

Maintenance notifications are a KV Cloud feature that allows the server to notify clients about:

Planned maintenance events
Failover operations
Node migrations
Cluster topology changes

The go-kv client supports three modes:

ModeDisabled: Client doesn't send CLIENT MAINT_NOTIFICATIONS ON command
ModeEnabled: Client forcefully sends the command, interrupts connection on error
ModeAuto (default): Client tries to send the command, disables feature on error

When to Disable Maintenance Notifications

You should disable maintenance notifications when:

Connecting to non-KV Cloud / KV Enterprise instances - Standard KV servers don't support this feature
You want to handle failovers manually - Your application has custom failover logic
Minimizing client-side overhead - You want the simplest possible client behavior
The KV server doesn't support the feature - Older KV versions or forks

Usage

Basic Example

import (
    "github.com/kv/go-kv/v9"
    "github.com/kv/go-kv/v9/maintnotifications"
)

rdb := kv.NewClient(&kv.Options{
    Addr: "localhost:6379",

    // Explicitly disable maintenance notifications
    MaintNotificationsConfig: &maintnotifications.Config{
        Mode: maintnotifications.ModeDisabled,
    },
})
defer rdb.Close()

Cluster Client Example

rdbCluster := kv.NewClusterClient(&kv.ClusterOptions{
    Addrs: []string{"localhost:7000", "localhost:7001", "localhost:7002"},

    // Disable maintenance notifications for cluster
    MaintNotificationsConfig: &maintnotifications.Config{
        Mode: maintnotifications.ModeDisabled,
    },
})
defer rdbCluster.Close()

Default Behavior (ModeAuto)

If you don't specify MaintNotifications, the client defaults to ModeAuto:

// This uses ModeAuto by default
rdb := kv.NewClient(&kv.Options{
    Addr: "localhost:6379",
    // MaintNotificationsConfig: nil means ModeAuto
})

With ModeAuto, the client will:

Try to enable maintenance notifications
If the server doesn't support it, silently disable the feature
Continue normal operation

Running the Example

Start a KV server:
```
kv-server --port 6379
```
Run the example:
```
go run main.go
```

Expected Output

=== Example 1: Explicitly Disabled ===
✓ Connected successfully (maintenance notifications disabled)
✓ SET operation successful
✓ GET operation successful: value1

=== Example 2: Default Behavior (ModeAuto) ===
✓ Connected successfully (maintenance notifications auto-enabled)

=== Example 3: Cluster Client with Disabled Notifications ===
Cluster not available (expected): ...

=== Example 4: Performance Comparison ===
✓ 1000 SET operations (disabled): 45ms
✓ 1000 SET operations (auto): 46ms

=== Cleanup ===
✓ Database flushed

=== Summary ===
Maintenance notifications can be disabled by setting:
  MaintNotificationsConfig: &maintnotifications.Config{
    Mode: maintnotifications.ModeDisabled,
  }

This is useful when:
  - Connecting to non-KV Cloud instances
  - You want to handle failovers manually
  - You want to minimize client-side overhead
  - The KV server doesn't support CLIENT MAINT_NOTIFICATIONS

Performance Impact

Disabling maintenance notifications has minimal performance impact. The main differences are:

Connection Setup: One less command (CLIENT MAINT_NOTIFICATIONS ON) during connection initialization
Runtime Overhead: No background processing of maintenance notifications
Memory Usage: Slightly lower memory footprint (no notification handlers)

In most cases, the performance difference is negligible (< 1%).

3.8 KiB Raw Permalink Blame History