// STRYKE-MYSQL — ENGINEERING REPORT

>_EXECUTIVE SUMMARY

stryke-mysql is one of the opt-in connector packages in the stryke ecosystem. MySQL / MariaDB client for stryke. Opt-in package, kept out of the stryke core binary so the daily-driver install stays slim. The mysql driver ships as a Rust cdylib that stryke dlopens in-process on first use MySQL.

The mysql crate pulls in a native libmysql-style protocol stack + TLS chains. Ships once as an opt-in package.

~ARCHITECTURE

In-process cdylib design: the stryke side is a thin .stk wrapper that calls FFI symbols on the dlopen'd library. No subprocess, no pipe — calls return on the same thread that made them.

$WHY OPT-IN (NOT BUILTIN)

The mysql crate pulls in a native libmysql-style protocol stack + TLS chains. Ships once as an opt-in package.

The trade-off is intentional. The core stryke binary stays under ~40 MB precisely because each connector ships separately. Daily-driver work (one-liners, awk replacement, data scripting) doesn't need MongoDB drivers, AWS SDKs, or Spark Connect bindings linked in.

&FFI ENVELOPE

JSON in / JSON out across the FFI boundary. Each MySQL::* wrapper serializes its args to a JSON dict and calls the matching mysql__* symbol on the dlopen'd cdylib; the cdylib returns a JSON CString the wrapper parses. catch_unwind on every call converts panics to JSON errors. The returned CString is freed via the cdylib-exported stryke_free_cstring, wired automatically by rust_ffi::load_cdylib. A mysql::Pool cache keyed by connection URL is held in OnceCell, so back-to-back calls reuse the same connection pool.

# request shape (built by the .stk wrapper)
{"<arg>": ...}

# response shape
{"result": ...}            # success — per-fn shape
{"error": "<msg>"}        # failure — wrapper die()s with the message

@FUNCTION SURFACE

The stryke side (lib/MySQL.stk) exposes 77 public MySQL::* functions. Most connection-aware verbs map 1:1 to a mysql__* FFI export; the higher-level CRUD helpers and several read shapes are composed on the stryke side, which is why there are more functions (77) than exports (66).

+DEPENDENCIES

The cdylib keeps a deliberately small, foundational dependency set. The release profile is tuned for a compact shippable artifact (opt-level = 3, lto = "thin", codegen-units = 1, strip = true, panic = "abort").

^TYPE ENCODING

Result rows cross the FFI boundary as JSON. Integer/float types become JSON numbers; DECIMAL is a string (the protocol sends it as bytes); DATE/DATETIME/TIMESTAMP/TIME become formatted strings; JSON columns are returned as raw JSON text; NULL becomes null. A BLOB/VARBINARY value is a string when it is valid UTF-8, otherwise it is prefixed "base64:" so consumers can detect and decode it. The full table is in the README "Type encoding" section.

/SCOPE

See the README's "Why this is a package" + "API reference" sections for the authoritative scope. The package is intentionally narrower than its underlying SDK / driver — the goal is "useful from a shell pipeline", not "complete API coverage". The connector currently exposes 77 stryke functions over 66 FFI exports, covering query, CRUD, transactions, introspection, admin, and connection-free SQL helpers. There is no separate CLI binary — the surface is the use MySQL package; the historical stryke-mysql-helper fork-per-call binary and its JSON-RPC daemon mode were replaced by the in-process cdylib + pool cache.

#PROJECT METADATA