5 posts filed under api.
The mongreldb-php client validates every permission string against a strict allowlist before it builds a GRANT statement, because DDL fragments cannot be bound as parameters and the classic prepared-statement advice does not cover them.
MongrelDB allows one primary key column per table by design, so a composite natural key like (tenant_id, slug) is modeled as a multi-column unique constraint enforced atomically at commit, with an optional surrogate auto-increment key when you need a point-lookup handle.
MongrelDB stored procedures are versioned, checksummed definitions installed over HTTP, and the pure PHP client exposes the whole lifecycle as five typed calls whose name-keyed argument arrays map directly onto the procedure's declared params.
The MongrelDB PHP client maps HTTP status codes to a small typed exception hierarchy, so a 401 is an AuthException, a 409 is a ConstraintException carrying the server's error code and the failing operation index, and your catch blocks read like the failure modes they handle.
A walk through the actual HTTP surface mongreldb-server exposes, from /sql and /txn to sessions, pagination cursors, and the /kit/* typed routes, and why plain HTTP was the right transport bet.
