Class EdgeVectorDataBuilderExtensions

Namespace

Qavren.Edge.VectorData

Assembly

Qavren.Edge.VectorData.dll

Registers the vector store, its collections and their schema on the Qavren.Edge builder.

public static class EdgeVectorDataBuilderExtensions

Inheritance

object

EdgeVectorDataBuilderExtensions

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Methods

AddVectorCollectionMigration(EdgeBuilder, int, string, VectorStoreCollectionDefinition, string?, Action<EdgeVectorStoreCollectionOptions>?)

The trim/AOT-safe variant: the model is built from the definition with CollectionModelBuilder.BuildDynamic, which reflects over nothing.

AddVectorCollectionMigration<TKey, TRecord>(EdgeBuilder, int, string, string?, Action<EdgeVectorStoreCollectionOptions>?)

RECOMMENDED. Emits the collection DDL as a sub-project 1 IEdgeMigration, so the schema is versioned by the existing migrator at startup order 100 with PRAGMA user_version bookkeeping instead of appearing on first use.

AddVectorCollection<TKey, TRecord>(EdgeBuilder, string, Action<EdgeVectorStoreCollectionOptions>?, string?)

The ad-hoc alternative: an IEdgeStartupTask at order 300 calling EnsureCollectionExistsAsync. Same SQL, no version bookkeeping.

The task opens a connection from inside the startup sequence, which works because IEdgeHost.EnsureStartedAsync returns at once when a startup task calls it: the order-10 open and the order-100 migrations have completed by order 300, and that is all this needs. AddVectorCollectionMigration<TKey, TRecord>(EdgeBuilder, int, string, string?, Action<EdgeVectorStoreCollectionOptions>?) remains the recommended path, because a migration is versioned and this is not.

AddVectorStore(EdgeBuilder, Action<EdgeVectorStoreOptions>?)

Registers EdgeVectorStore and MEVD's VectorStore over the named sub-project 1 database, plus the diagnostics contributor and the lifecycle observer.

Embedding generator resolution, which is what makes the four-call path work. The registered factory resolves IEmbeddingGenerator from the container with GetService - never GetRequiredService, because a store used only with pre-computed ReadOnlyMemory<T> vectors needs no generator and demanding one would break that. The result goes to EdgeVectorStore's embeddingGenerator parameter, which applies it only where EmbeddingGenerator is still null.

The query generator is then resolved from the generator itself, by service key, with no reference to Qavren.Edge.Embeddings.Onnx: the key is this package's own QueryGeneratorServiceKey, the call is GetService rather than the ONNX package's AsQueryGenerator() convenience, and it asks for the non-generic IEmbeddingGenerator - a third-party generator may be typed IEmbeddingGenerator<DataContent, Embedding<float>>, and asking for a closed generic it does not implement would return null and quietly lose the query lane.

Builder-call order does not matter, because the factory runs at resolve time.

AddVectorStore(EdgeBuilder, string, Action<EdgeVectorStoreOptions>?)

Keyed variant. Resolves the keyed IEmbeddingGenerator under the same name first, then the unkeyed one, so a named store pairs with a named generator by convention.