Skip to main content

VectorDB Service (removed)

client.vectordb and kamiwaza_sdk/services/vectordb.py no longer exist. Vector databases, collections and vector operations are part of the Context Service, reached through client.context. Code that still calls client.vectordb fails with AttributeError: 'KamiwazaClient' object has no attribute 'vectordb'.

What changed​

  • Every call names the VectorDB it targets (vectordb_id).
  • Every VectorDB lives inside a workroom, and writes need a non-Global one. With a personal access token, pass workroom_id= on each call, or use client.workroom_scope(workroom_id) as the Context Service page shows.
  • Search takes a list of query vectors and returns {"results": [[hit, ...], ...]}: one list of hits per query vector. Each hit carries distance (with the default inner-product metric, higher is closer) and entity (the stored fields named in output_fields).
  • Collections are listed as dictionaries (name, dimension, vector_count, ...), not as bare names.
  • insert_vectors sends metadata and field_list as given. The removed insert() filled any missing model_name, source, catalog_urn, offset and filename with empty values and, without a field_list, built one from the first metadata entry. Give every row those fields, and pass field_list for any custom fields.

Old call to new call​

RemovedUse instead
client.vectordb.create_vectordb(...)client.context.create_vectordb(name=..., engine="milvus", workroom_id=...)
client.vectordb.get_vectordbs(engine=...)client.context.list_vectordbs(workroom_id=...); there is no engine filter, so filter the returned entries on their engine field
client.vectordb.get_vectordb(vectordb_id)client.context.get_vectordb(vectordb_id, workroom_id=...)
client.vectordb.remove_vectordb(vectordb_id)client.context.delete_vectordb(vectordb_id, workroom_id=...)
client.vectordb.insert(vectors, metadata, collection_name, field_list)client.context.insert_vectors(vectordb_id, collection_name=..., vectors=..., metadata=..., field_list=..., workroom_id=...)
client.vectordb.insert_vectors(InsertVectorsRequest(...))client.context.insert_vectors(...) as above, passing the request's collection_name, vectors, metadata and field_list; drop dimensions, which insert_vectors does not take
client.vectordb.search(query_vector, collection_name, limit, output_fields)client.context.query_vectors(vectordb_id, collection_name=..., vectors=[query_vector], limit=..., output_fields=..., workroom_id=...)
client.vectordb.search(..., metric_type="IP", nprobe=10)client.context.query_vectors(..., params={"metric_type": "IP", "params": {"nprobe": 10}}); without params the server uses inner product with nprobe 512
client.vectordb.search_vectors(SearchVectorsRequest(...))client.context.query_vectors(...) as above: the request's query_vectors become vectors= and its search_params become params=, with collection_name, limit and output_fields unchanged; drop anns_field, which query_vectors does not take
client.vectordb.list_collections()client.context.list_collections(workroom_id=..., vectordb_id=...)
client.vectordb.drop_collection(name)client.context.delete_collection(workroom_id=..., collection_name=name, vectordb_id=...)

The request models in kamiwaza_sdk.schemas.vectordb (InsertVectorsRequest, SearchVectorsRequest and the rest) belonged to the removed service; the Context Service takes plain keyword arguments instead.

A new Milvus VectorDB starts in pending and takes a minute or two to report running with an endpoint; poll client.context.get_vectordb(...) until it does. Even then, while the cluster settles, the first insert can be refused with a 503 whose detail has code: resource_not_ready and status: pending. Core refuses the write before touching anything, so retrying that exact answer is safe. The RAG examples do both.

workroom_id = str(client.workrooms.create("rag-demo", "ephemeral").id)
db = client.context.create_vectordb(name="rag-demo", engine="milvus", workroom_id=workroom_id)

# ... once str(client.context.get_vectordb(db["id"], workroom_id=workroom_id)["status"]).lower() == "running":
client.context.insert_vectors(
db["id"],
collection_name="docs",
vectors=embeddings,
metadata=[{"source": "a.md", "offset": 0}],
workroom_id=workroom_id,
)
response = client.context.query_vectors(
db["id"],
collection_name="docs",
vectors=[query_embedding],
limit=5,
output_fields=["source", "offset"],
workroom_id=workroom_id,
)
hits = response["results"][0]

Current Kamiwaza releases return each hit as the text of a Python dict rather than a JSON object. The RAG examples (07_kamiwaza_rag_demo.ipynb, 10_rag_end_to_end_sdk.ipynb and interactive_rag.py) read hits through a small hit_fields() helper that accepts both forms.