Different databases have different schema configuration options that aren't universal, and therefore cannot be captured by the abstraction. We can have an extensibility mechanism to allow such options to be specified via "annotations" on the abstraction's schema definition objects.
One approach would be to have provider-specific subclasses of e.g. VectorStoreRecordDataProperty; the downside of that approach is that the schema can only be used on a single vector database (applications targeting multiple vector databases - probably rare - would have to have two separate copies of the schema).
The other approach would be a bag-of-properties (e.g. Dictionary<string, object?>, along with some user-facing extension methods which allow nice, strongly-typed management of the data in the bag.
Possible usages:
/cc @westey-m
Different databases have different schema configuration options that aren't universal, and therefore cannot be captured by the abstraction. We can have an extensibility mechanism to allow such options to be specified via "annotations" on the abstraction's schema definition objects.
One approach would be to have provider-specific subclasses of e.g. VectorStoreRecordDataProperty; the downside of that approach is that the schema can only be used on a single vector database (applications targeting multiple vector databases - probably rare - would have to have two separate copies of the schema).
The other approach would be a bag-of-properties (e.g.
Dictionary<string, object?>, along with some user-facing extension methods which allow nice, strongly-typed management of the data in the bag.Possible usages:
/cc @westey-m