mirror of
https://github.com/basicmachines-co/basic-memory
synced 2026-06-21 13:47:35 +00:00
phernandez
a85767ad92
SQLite stores search_index as an FTS5 virtual table, which can't carry a foreign key, so the ON DELETE CASCADE from search_index.project_id to project.id only applies on Postgres. On SQLite, deleting a project left its FTS rows behind — and when auto-increment handed the same id to a new project, the leftover rows masqueraded as the new tenant's data and leaked into searches scoped to that project. - ProjectRepository.delete now explicitly purges search_index and search_vector_chunks for the project id in the same session before the ORM delete. Idempotent on Postgres (the cascade FK still runs). - One-time cleanup migration sweeps two leftover shapes: rows whose project_id is gone, and rows whose entity_id is gone (the larger class from id reuse). Guarded by table-existence checks so fresh SQLite installs — where search_index is created at runtime by init_search_index, not by Alembic — don't fail the upgrade. - Regression test seeds both derived tables, calls remove_project, and asserts both come out clean. Verified red on pre-fix code. Signed-off-by: phernandez <paul@basicmachines.co>