docs(caching): the cache metrics table was missing misses and the two stale-while-revalidate counters

docs: publish v2.2 as latest (#2111)

docs(caching): a declared primary_key is a row constraint, not the cache key The caching refresh-mode page said a declared `acceleration.primary_key` replaces request metadata as the cache key, and its worked example passed a YAML list. Neither is true. A cache lookup is built from the request alone, so a key over response fields could not serve one even in principle; `primary_key` is a uniqueness constraint on the rows the accelerator stores. And `primary_key` deserializes as a string in every release, so the list form never parsed — the whole Spicepod is rejected at load. The example now projects the response fields it keys on with a `columns:` block and passes the key as a parenthesized string. That projection is only available from v2.0.0, so the 1.10.x and 1.11.x copies drop the example instead and state what a key can name there.

docs: publish v2.2 as latest (#2111)

docs(cluster): runtime.scheduler.params keys take the s3_ prefix

docs: publish v2.2 as latest (#2111)

docs: publish v2.2 as latest (#2111)

docs(models): paged attention is requested automatically, not unconditionally enabled The local-model paged-attention note collapsed three branches into one absolute sentence. `MistralLlama::paged_attention_config` returns `None` when the device is CPU or when the build is not `all(feature = "cuda", target_family = "unix")`, and the engine downgrades to dense attention again for architectures with no paged kernel (the Multi-head Latent Attention GGUFs) — so a CUDA+Unix build is necessary, not sufficient. From v2.2.0 (spiceai/spiceai#11990) the note is also wrong to say no configuration is needed: `FileModelParams::paged_attention` accepts `auto` (default) or `disabled`, and `disabled` forces dense attention. It is a `from: file:` parameter only — `HuggingFaceModelParams` has no such field and `from_hf` calls `paged_attention_config` unconditionally. Scoped accordingly: the branch distinction lands in v2.0.x-v2.3.x and vNext; the escape hatch only in v2.2.x, v2.3.x and vNext.

docs: publish v2.2 as latest (#2111)

docs(observability): the three cache metric families are registered alike but only the SQL cache records them generate_cache_metrics! registers the same instrument set for results, search_results and embeddings, and CacheMetrics::init() publishes every counter at zero, so a scrape carries all three prefixes in full. The metrics table documented the full set only for results_cache_*, leaving the other two families four series short, and it described the two stale-while-revalidate counters it did list for them as if they reported real activity. Every stale-serving and invalidation counter is incremented only through cache::metrics::sql_results::* and impl CacheMetrics for CachedQueryResult; the embeddings and search_results implementations are never reached from a production path, so those series stay at the zero they are published at. Reproduced against spiced v2.3.0: a /metrics scrape emits all 14 instruments for each of the three families, with the full reason/mode/outcome label cross-product at zero. Scoped per release: stale_rejections first shipped in v2.1.5, the other three in v2.3.0, so version-2.0.x and older are unchanged and the 2.1.x/2.2.x notes name only the counters those releases register.

docs: Sync the cookbook page and recipe links with spiceai/cookbook (#2318) * Sync the cookbook page with the current spiceai/cookbook recipes List all 122 current recipes (up from 79) and leave out evals, llm-judge, and websearch, which the cookbook marks deprecated in v2.0+. - Correct entries that pointed at the wrong recipe or described an old version: Results Caching linked the Caching Accelerator recipe, Nvidia NIM on Kubernetes linked the EC2 recipe, Hashed Partitioning now uses Cayenne, and Federated SQL Query no longer uses Dremio. - Add the missing recipes, including Cayenne, async queries, native PostgreSQL/MySQL/MongoDB CDC, DynamoDB Streams, HTTP, Redshift, ScyllaDB, SMB, the catalog connectors, full-text search, distributed query, and Spice as an MCP server. - Add Change Data Capture and Advanced Topics sections. Local Dataset Replication was tagged for no rendered section, so it never appeared. - Show guides in Sample Applications and Guides instead of Security. - Align Core Features with the cookbook's core scenarios and feature Cayenne as the data accelerator. - Label recipes that need Spice.ai Enterprise. - Remove forbidden words (enhance, leverage, utilize, robust) from section intros. * Fix broken and stale cookbook recipe references across doc versions Every version links to the recipes on cookbook trunk, so these corrections apply to each version that carries them. - Query Federation: replace the walkthrough with the current Federated SQL Query recipe, which joins NYC taxi trips in S3 with taxi zones in PostgreSQL. The old walkthrough logged in to a demo Dremio, ran 'spice add spiceai/fed-demo' (that Spicepod no longer exists on Spicerack), and ran 'cd demo' twice. The new steps and output come from a run of the recipe on Spice v2.3.2. - FAQ: the RAG recipe link (cookbook/tree/trunk/rag) never existed; link the RAG use-case page instead. - Use cases: fix duckdb/accelerator/README and federation/README links that were missing the .md extension. - PostgreSQL connector: link the connector recipe instead of the accelerator recipe, and fix 'configure Supabase a data connector'. - ODBC connector: the recipe now connects to MySQL with the MariaDB driver, not Postgres. - Glue catalog connector: its recipe configures the Glue Catalog Connector, not the Data Connector. - Release notes: fix three recipe links that pointed at moved or malformed paths. * Link docs pages to their cookbook recipes 49 cookbook recipes had no link from any docs page. Add a Cookbook section, or a bullet in an existing one, on the matching page in vNext and 2.3.x. Covered pages include CDC (PostgreSQL, MySQL, Aurora MySQL, MongoDB), the catalog connectors (DuckLake, MySQL, SQL Server, Unity Catalog, Databricks, Iceberg Hadoop, PostgreSQL CDC), acceleration (partitioning, snapshots, indexes, constraints, views, caching, cron refresh, dual-dataset registration), search, distributed query and async queries, MCP, LLM memory, text-to-SQL, the ai() function, models (OpenAI, DeepSeek, filesystem, xAI, NVIDIA NIM on Kubernetes), API keys, ADBC, JDBC, the SDKs, and Cloud Connect. The sidecar and microservice architecture partials, which every version shares, link their recipes too. Related updates: - The docs landing page lists Cayenne among the accelerators and links the Cayenne recipe. - The Cayenne Transactions intro also covers tables configured for durable write-back, matching the section's own requirements. - The FAQ says the cookbook has over 120 recipes, up from over 65.

docs(embeddings): the chunk offset column is <column>_offset, not _offsets (#2170) Every page that documents bring-your-own chunked embeddings named the required offset column '<column_name>_offsets'. The runtime looks for '<column>_offset': offset_col! in runtime-search generates '{col}_offset', ChunkedSearchIndex ::chunking_offset_col formats the same, and base_col strips '_offset'. The consequence is silent. EmbeddingTable::base_table_has_embedding_column looks the column up by that exact name and, unlike the two neighbouring early-returns, logs nothing when it is missing - it just returns false, so the column is not treated as precomputed and Spice re-embeds it from scratch. A user who followed the docs pays for embeddings they already had and gets no diagnostic explaining why. The vector-search page already contradicted itself: its 'describe sales' example for the chunked case shows 'address_offset', matching the code, one section below the constraint that asked for '_offsets'. Swept all 11 doc sets and all three page types that carry the claim.

docs: publish v2.2 as latest (#2111)

docs: publish v2.2 as latest (#2111)

docs: publish v2.2 as latest (#2111)

docs: publish v2.2 as latest (#2111)

docs: publish v2.2 as latest (#2111)

docs: publish v2.2 as latest (#2111)