sqlrite 0.1.12__tar.gz → 0.1.14__tar.gz

{sqlrite-0.1.12 → sqlrite-0.1.14}/Cargo.lock

@@ -3736,7 +3736,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-desktop"
-version = "0.1.12"
+version = "0.1.14"
 dependencies = [
  "serde",
  "serde_json",
@@ -3748,7 +3748,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-engine"
-version = "0.1.12"
+version = "0.1.14"
 dependencies = [
  "clap",
  "env_logger",
@@ -3763,7 +3763,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-ffi"
-version = "0.1.12"
+version = "0.1.14"
 dependencies = [
  "cbindgen",
  "sqlrite-engine",
@@ -3771,7 +3771,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-nodejs"
-version = "0.1.12"
+version = "0.1.14"
 dependencies = [
  "napi",
  "napi-build",
@@ -3781,7 +3781,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-python"
-version = "0.1.12"
+version = "0.1.14"
 dependencies = [
  "pyo3",
  "sqlrite-engine",

{sqlrite-0.1.12 → sqlrite-0.1.14}/Cargo.toml

@@ -27,7 +27,7 @@ resolver = "3"
 # `package =` key so the import name stays `sqlrite` internally:
 #     sqlrite = { package = "sqlrite-engine", path = "…" }
 name = "sqlrite-engine"
-version = "0.1.12"
+version = "0.1.14"
 authors = ["Joao Henrique Machado Silva <joaoh82@gmail.com>"]
 edition = "2024"
 rust-version = "1.85"

{sqlrite-0.1.12 → sqlrite-0.1.14}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sqlrite
-Version: 0.1.12
+Version: 0.1.14
 Classifier: Development Status :: 3 - Alpha
 Classifier: Intended Audience :: Developers
 Classifier: License :: OSI Approved :: MIT License

{sqlrite-0.1.12 → sqlrite-0.1.14}/desktop/package.json

@@ -1,7 +1,7 @@
 {
   "name": "sqlrite-desktop-frontend",
   "private": true,
-  "version": "0.1.12",
+  "version": "0.1.14",
   "type": "module",
   "scripts": {
     "dev": "vite",

{sqlrite-0.1.12 → sqlrite-0.1.14}/docs/phase-7-plan.md

@@ -158,6 +158,14 @@ SELECT id, title FROM docs ORDER BY embedding <-> [0.1, ...] LIMIT 10;
 
 **LOC estimate:** ~700-900 lines. The big sub-phase.
 
+> **Scope correction (2026-04-27, post-7c):** Re-scoping during implementation showed 7d works out to ~1300 LOC across three logical chunks, more than the original ~700-900 estimate and too much for one reviewable PR. Splitting into three:
+>
+> - **✅ 7d.1 — Pure HNSW algorithm** *(~700 LOC, shipped in v0.1.13).* `src/sql/hnsw.rs` standalone module: insert + search + layer assignment + beam search per layer + L2/cosine/dot distance dispatch. No SQL integration yet — vectors are passed in via a `get_vec` closure so the algorithm doesn't depend on table types. Tests verify recall@k ≥ 0.95 vs brute-force on randomly-generated vector sets; deterministic via a fixed RNG seed.
+> - **✅ 7d.2 — SQL integration** *(~500 LOC).* `CREATE INDEX … USING hnsw (col)` parser + engine, INSERT wiring (also calls `hnsw.insert()` incrementally), query optimizer hook (recognizes `ORDER BY vec_distance_l2(col, literal) LIMIT k` and probes the HNSW instead of full-scanning). HNSW lives in memory only at this point; the **CREATE INDEX SQL persists in `sqlrite_master` and reopen rebuilds the graph from current rows** — partial persistence ahead of 7d.3. DELETE/UPDATE on HNSW-indexed tables refused with helpful error pointing at 7d.3.
+> - **7d.3 — Persistence** *(~300 LOC).* Wire HNSW into the cell format: new `KIND_HNSW` cell tag, page-tree storage parallel to secondary indexes, save/reopen round-trip without rebuild. Also adds DELETE/UPDATE support since the persisted form gives us a natural rebuild trigger.
+>
+> Each 7d.x ships as its own PR + release wave. The user-facing value lands at 7d.2; 7d.3 closes the persistence loop. 7d.1 is foundational but ships a tested algorithmic primitive on its own — useful as documentation of the engine's "from scratch" theme.
+
 **Tests:** recall@k vs brute-force baseline (should be ≥ 0.95 on standard benchmark vectors); insert performance; delete semantics; persistence roundtrip.
 
 ---

{sqlrite-0.1.12 → sqlrite-0.1.14}/docs/roadmap.md

@@ -473,7 +473,7 @@ Approved sub-phases (Q1–Q10 resolved):
 - **✅ 7a — `VECTOR(N)` column type** *(v0.1.10)* — dense fixed-dimension f32 storage via the existing cell encoding; format bumped to v4. Bracket-array literal syntax `[0.1, 0.2, …]` (Q7).
 - **✅ 7b — Distance functions** *(v0.1.11)* — `vec_distance_l2/cosine/dot`, plus the ORDER BY-expressions parser change so KNN queries work end-to-end. Operators (`<->` `<=>` `<#>`) deferred to **7b.1** — sqlparser doesn't parse them natively, contradicting Q6's "tiny parser change" assumption.
 - **✅ 7c — Brute-force KNN executor optimization** — bounded `BinaryHeap` of size k for `ORDER BY <expr> LIMIT k`. ~1.8× faster than full-sort at N=10k for cheap keys; bigger gains on expensive keys like `vec_distance_l2`.
-- **7d — HNSW ANN index** — `CREATE INDEX … USING hnsw (col)`; persisted as cell-encoded graph. Fixed defaults `M=16, ef_construction=200, ef_search=50` (Q2).
+- **7d — HNSW ANN index** — split into 7d.1 (✅ algorithm), 7d.2 (✅ SQL integration), 7d.3 (persistence). `CREATE INDEX … USING hnsw (col)`; fixed defaults `M=16, ef_construction=200, ef_search=50` (Q2).
 - **7e — JSON column type + path queries** — `JSON` data type stored as bincoded `serde_json::Value` (Q3); `json_extract` / `json_array_length` / `json_object_keys` / `json_type`.
 - **7f — ~~Full-text search with BM25~~** — **deferred to Phase 8** (Q1).
 - **7g — `ask()` API across the product surface** — natural-language → SQL via Anthropic API (Q4), Anthropic-first then OpenAI + Ollama follow-ups. Foundational 7g.1 introduces a new `sqlrite-ask` crate (Q10 — separate crate, not a feature flag). Thin per-product adapters in 7g.2-7g.8 cover REPL, desktop, Python, Node.js, Go, WASM (JS-callback shape per Q9), and the MCP `ask` tool.

{sqlrite-0.1.12 → sqlrite-0.1.14}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "maturin"
 
 [project]
 name = "sqlrite"
-version = "0.1.12"
+version = "0.1.14"
 description = "Python bindings for SQLRite — a small, embeddable SQLite clone written in Rust."
 authors = [{ name = "Joao Henrique Machado Silva", email = "joaoh82@gmail.com" }]
 license = { text = "MIT" }

{sqlrite-0.1.12 → sqlrite-0.1.14}/sdk/python/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "sqlrite-python"
-version = "0.1.12"
+version = "0.1.14"
 authors = ["Joao Henrique Machado Silva <joaoh82@gmail.com>"]
 edition = "2024"
 rust-version = "1.85"

{sqlrite-0.1.12 → sqlrite-0.1.14}/src/sql/db/table.rs

@@ -1,5 +1,6 @@
 use crate::error::{Result, SQLRiteError};
 use crate::sql::db::secondary_index::{IndexOrigin, SecondaryIndex};
+use crate::sql::hnsw::HnswIndex;
 use crate::sql::parser::create::CreateQuery;
 use std::collections::{BTreeMap, HashMap};
 use std::fmt;
@@ -118,12 +119,32 @@ pub struct Table {
     /// add more. Looking up an index: iterate by column name, or by index
     /// name via `Table::index_by_name`.
     pub secondary_indexes: Vec<SecondaryIndex>,
+    /// HNSW indexes on VECTOR columns (Phase 7d.2). Maintained in lockstep
+    /// with row storage on INSERT (incremental); rebuilt on open from the
+    /// persisted CREATE INDEX SQL. The graph itself is NOT yet persisted —
+    /// see Phase 7d.3 for cell-encoded graph storage.
+    pub hnsw_indexes: Vec<HnswIndexEntry>,
     /// ROWID of most recent insert.
     pub last_rowid: i64,
     /// PRIMARY KEY column name, or "-1" if the table has no PRIMARY KEY.
     pub primary_key: String,
 }
 
+/// One HNSW index attached to a table. Phase 7d.2 only supports L2
+/// distance; cosine and dot are 7d.x follow-ups (would require either
+/// distinct USING methods like `hnsw_cosine` or a `WITH (metric = …)`
+/// clause — see `docs/phase-7-plan.md` for the deferred decision).
+#[derive(Debug, Clone)]
+pub struct HnswIndexEntry {
+    /// User-supplied name from `CREATE INDEX <name> …`. Unique across
+    /// both `secondary_indexes` and `hnsw_indexes` on a given table.
+    pub name: String,
+    /// The VECTOR column this index covers.
+    pub column_name: String,
+    /// The graph itself.
+    pub index: HnswIndex,
+}
+
 impl Table {
     pub fn new(create_query: CreateQuery) -> Self {
         let table_name = create_query.table_name;
@@ -194,6 +215,11 @@ impl Table {
             columns: table_cols,
             rows: table_rows,
             secondary_indexes,
+            // HNSW indexes only land via explicit CREATE INDEX … USING hnsw
+            // statements (Phase 7d.2); never auto-created at CREATE TABLE
+            // time, because there's no UNIQUE-style constraint that
+            // implies a vector index.
+            hnsw_indexes: Vec::new(),
             last_rowid: 0,
             primary_key,
         }
@@ -217,6 +243,10 @@ impl Table {
             columns: self.columns.clone(),
             rows: Arc::new(Mutex::new(cloned_rows)),
             secondary_indexes: self.secondary_indexes.clone(),
+            // HnswIndexEntry derives Clone, so the snapshot owns its own
+            // graph copy. Phase 4f's snapshot-rollback semantics require
+            // the snapshot to be fully decoupled from live state.
+            hnsw_indexes: self.hnsw_indexes.clone(),
             last_rowid: self.last_rowid,
             primary_key: self.primary_key.clone(),
         }
@@ -813,16 +843,57 @@ impl Table {
 
             // Step 2: maintain the secondary index (if any). insert() is a
             // no-op for Value::Null and cheap for other value kinds.
-            if let Some(v) = typed_value {
+            if let Some(v) = typed_value.clone() {
                 if let Some(idx) = self.index_for_column_mut(key) {
                     idx.insert(&v, next_rowid)?;
                 }
             }
+
+            // Step 3 (Phase 7d.2): maintain any HNSW indexes on this column.
+            // The HNSW algorithm needs access to other rows' vectors when
+            // wiring up neighbor edges, so build a get_vec closure that
+            // pulls from the table's row storage (which we *just* updated
+            // with the new value).
+            if let Some(Value::Vector(new_vec)) = typed_value {
+                self.maintain_hnsw_on_insert(key, next_rowid, &new_vec);
+            }
         }
         self.last_rowid = next_rowid;
         Ok(())
     }
 
+    /// After a row insert, push the new (rowid, vector) into every HNSW
+    /// index whose column matches `column`. Split out of `insert_row` so
+    /// the borrowing dance — we need both `&self.rows` (read other
+    /// vectors) and `&mut self.hnsw_indexes` (insert into the graph) —
+    /// stays localized.
+    fn maintain_hnsw_on_insert(&mut self, column: &str, rowid: i64, new_vec: &[f32]) {
+        // Snapshot the current vector storage so the get_vec closure
+        // doesn't fight with `&mut self.hnsw_indexes`. For a typical
+        // HNSW insert we touch ef_construction × log(N) other vectors,
+        // so the snapshot cost is small relative to the graph wiring.
+        let mut vec_snapshot: HashMap<i64, Vec<f32>> = HashMap::new();
+        {
+            let row_data = self.rows.lock().expect("rows mutex poisoned");
+            if let Some(Row::Vector(map)) = row_data.get(column) {
+                for (id, v) in map.iter() {
+                    vec_snapshot.insert(*id, v.clone());
+                }
+            }
+        }
+        // The new row was just written into row storage — make sure the
+        // snapshot reflects it (it should, but defensive).
+        vec_snapshot.insert(rowid, new_vec.to_vec());
+
+        for entry in &mut self.hnsw_indexes {
+            if entry.column_name == column {
+                entry.index.insert(rowid, new_vec, |id| {
+                    vec_snapshot.get(&id).cloned().unwrap_or_default()
+                });
+            }
+        }
+    }
+
     /// Print the table schema to standard output in a pretty formatted way.
     ///
     /// # Example