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
{{ message }}
Repository navigation
VectorIndex wrapper silently returns no results after REBUILD INDEX #116
A VectorIndex wrapper that is held across a SQL REBUILD INDEX keeps answering, but with an empty result and no error.
Measured on the released wheel arcadedb-embedded 26.10.2.post1 with 2,000 vectors of dimension 16 (type Doc, property embedding):
Step
find_nearest(q, k=5) rows
get_stats()["totalVectors"]
Before REBUILD INDEX \Doc[embedding]``
5
2000
After, the old wrapper
0
0
After, a wrapper re-fetched with db.schema.get_vector_index("Doc", "embedding")
5
2000
Cause: VectorIndex.__init__ stores the Java index object in self._java_index and memoizes the resolved LSM indexes in self._lsm_indexes. REBUILD INDEX drops the index and builds a new Java object under the same name. The old object reports isValid() false, but its search path does not check that, so it answers empty instead of raising. A long-lived application (an agent memory, for example) that keeps one wrapper then silently loses all its search results after a rebuild.
Wanted: the wrapper remembers the index name. When its cached Java index is no longer valid, it re-resolves the index from the schema by name and resets _lsm_indexes and _pq_ready. If the name no longer resolves (the index was dropped for good), it raises an ArcadeDBError that names the index, and never returns an empty result. The check costs one isValid() crossing per public call on the cached object. The native build already resolves the index by name on every call, so it needs no change.
Activity
VectorIndex: re-resolve the Java index by name after REBUILD INDEX (#117