v1.6.0: Route database access through your own client, richer demo

SLayer 1.6.0

This release lets you route SLayer's database access through your own client, and gives the demo more data to explore.

Route database access through your own client

If you embed SLayer, pass a client_factory to SlayerQueryEngine (or to a local-mode SlayerClient, create_app, create_mcp_server, the Postgres facade or the Flight server). Every database access then goes through the client it builds, for example a gateway that holds the database credentials. See SQL Clients.

Ingesting from Python is now a one-liner on the engine: engine.ingest_sync(ds, schema="public"), or await engine.ingest(ds, ...). Code written for 1.5.0 keeps working and shows a FutureWarning with the new form.

Demo and docs

Demo orders now have a status (completed, refunded, cancelled), and stores belong to regions, so you can group by stores.regions.name. Every query example in the docs now runs on the demo.

Fixes

• slayer validate-models no longer reports numeric columns of SQL-backed SQLite models as type drift, and --cardinality works on async drivers.
• The MCP datasource tools no longer stall other requests while they read the database.
• If SLayer can't list a schema's views, ingestion reports an error instead of ingesting only the tables, and drift checks refuse instead of proposing deletes.

Deprecations

These still work until 2.0 but now warn: --models-dir and SLAYER_MODELS_DIR (use --storage / SLAYER_STORAGE), the MCP inspect_model tool (use inspect), and MemoryNotFoundError.identifier (use memory_id). The Docker image now sets SLAYER_STORAGE=/data, so if you override its command and set only SLAYER_MODELS_DIR, set SLAYER_STORAGE instead.