You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-**Intelligent Sync**: Content-hash change detection skips unchanged files, atomically replaces modified ones, and cleans up deleted ones
39
-
-**Transactional Safety**: Every sync operation runs inside a SAVEPOINT transaction - either fully succeeds or fully rolls back, no partially-indexed content
39
+
-**Transactional Safety**: Text/file ingests run inside SAVEPOINT transactions, and directory sync uses transactional cleanup plus per-file transactional updates so failed files do not leave partial rows behind
40
40
-**Efficient Storage**: Binary embeddings with configurable dimensions
41
41
-**Embedding Cache**: Automatically caches computed embeddings, so re-indexing the same text skips redundant API calls and computation
42
42
-**Flexible Embedding**: Use local models (llama.cpp) or [vectors.space](https://vectors.space) remote API
@@ -61,6 +61,9 @@ sqlite-memory bridges these concepts, allowing any SQLite-powered application to
61
61
62
62
## Getting Started
63
63
64
+
> [!IMPORTANT]
65
+
> Databases created with sqlite-memory versions earlier than `1.0.0` must be rebuilt before use with `1.0.0+`, because the internal schema changed.
66
+
64
67
### Prerequisites
65
68
66
69
- SQLite
@@ -74,7 +77,7 @@ sqlite-memory bridges these concepts, allowing any SQLite-powered application to
SELECT memory_add_text('SQLite is a C-language library that implements a small, fast,
@@ -160,7 +163,7 @@ All `memory_add_*` functions use content-hash change detection to avoid redundan
160
163
1.**Cleanup**: Removes database entries for files that no longer exist on disk
161
164
2.**Scan**: Recursively processes all matching files - adding new ones, replacing modified ones, and skipping unchanged ones
162
165
163
-
Every sync operation is wrapped in a SQLite SAVEPOINT transaction. If anything fails mid-sync (embedding error, disk issue, etc.), the entire operation rolls back cleanly. There is no risk of partially-indexed files or orphaned entries.
166
+
`memory_add_text()` and `memory_add_file()` each run inside a SQLite SAVEPOINT transaction. `memory_add_directory()` performs its cleanup pass transactionally and then processes each file in its own transaction. If one file fails, that file rolls back cleanly and previously-committed files remain valid; there are no partially-indexed rows or orphaned chunk/FTS entries for the failed file.
164
167
165
168
This makes all sync functions safe to call repeatedly - for example, on a cron schedule or at agent startup - with minimal overhead.
166
169
@@ -258,8 +261,8 @@ FROM dbmem_content;
258
261
-- Delete by context
259
262
SELECT memory_delete_context('old-project');
260
263
261
-
-- Delete specific memory
262
-
SELECT memory_delete(1234567890);
264
+
-- Delete specific memory by hash
265
+
SELECT memory_delete('9e3779b97f4a7c15');
263
266
264
267
-- Clear all memories
265
268
SELECT memory_clear();
@@ -279,8 +282,11 @@ cd sqlite-memory
279
282
# Build (full build with local + remote engines)
280
283
make
281
284
282
-
# Run tests
285
+
# Run parser/core unit tests + extension loading smoke test
0 commit comments