Sharding keys

[lemenkov]

Add sharding key support — oracledb's connection/pool shardingkey= / supershardingkey= so a connection can be routed to the right shard of a sharded database.

Scope

• oracle.connect(..., shardingkey=[...], supershardingkey=[...]) (and pool equivalents) — oracledb-compatible API.
• Encode the sharding key values into the connect/auth flow the listener uses to route to a shard (RE the exact pairs/descriptor fields oracledb-thin emits).
• Type handling for key components (number, varchar, date, raw).

Notes / risks

• A true sharded-DB testbed is heavy to stand up; the wire encoding can be RE'd from an oracledb-thin capture even against a non-sharded server (the client sends the key regardless), then full routing verified opportunistically.
• Smaller surface than SODA but testbed-constrained for end-to-end routing — flag if it should move to a backlog/no-milestone if a sharded testbed proves impractical.
• Sync + async parity; offline fixtures for the encoding.

Part of the 1.7.0 advanced-parity milestone.

[lemenkov]

Deferred out of 1.7.0 (decision with Peter, 2026-06-21). Sharding is thick-mode-only in oracledb (thin raises DPY-3001: 'sharding is only supported in thick mode'), so there is no oracledb-thin reference; the wire encoding is RE-able from an Oracle JDBC capture, but end-to-end shard routing also needs a sharded database testbed. Smaller surface than #163 but reference- and testbed-constrained. Kept open as backlog.

[lemenkov]

Current status (2026-06-24): open backlog, no milestone. The body's "Part of the 1.7.0 milestone" line is historical — sharding was deferred out of 1.7.0 on 2026-06-21 and never re-milestoned. (For the record, 1.7.0, 1.8.0 and 1.9.0 have since shipped.)

Still blocked for the same reasons, unchanged since the deferral:

• No oracledb-thin reference — sharding is thick-mode-only in oracledb (thin raises DPY-3001), so there is no thin capture to RE the wire encoding from; it would need an Oracle JDBC-thin capture instead.
• No sharded-DB testbed — end-to-end shard routing can't be verified against the local 9i/10g/11g/21c/23ai instances; a sharded database would have to be stood up.

The client-side bind/connect encoding could still be RE'd from a JDBC capture against a non-sharded server (the key is sent regardless), but without a sharded testbed the routing can't be validated, so it stays backlog rather than entering a milestone. The current 2.0.0 milestone is reserved for Oracle Cloud / ADB connectivity (#125 + #127); sharding remains unscheduled until a reference + testbed become practical.