Skip to content

VectorIndex wrapper silently returns no results after REBUILD INDEX #116

Closed

Description

@tae898

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions