Skip to content

.Net: [MEVD] Switch IVectorStore and IVectorStoreRecordCollection from interfaces to abstract base classes #11775

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
roji opened this issue Apr 28, 2025 · 0 comments
Assignees
Labels
Build Features planned for next Build conference msft.ext.vectordata Related to Microsoft.Extensions.VectorData .NET Issue or Pull requests regarding .NET code

Comments

@roji
Copy link
Member

roji commented Apr 28, 2025

The two main types exposed by MEVD - IVectorStore and IVectorStoreRecordCollection - are interfaces; we will probably be changing these to abstract base classes. Some context:

  • We'd like to be able to add methods with default implementations without breaking implementations; we don't want to end up in a place like System.Data, which was originally interface-based (IDbConnection, IDbCommand) and right afterwards introduced abstract base classes instead (DbConnection, DbCommand).
    • One concrete example is a new API for instantiating a collection in a NativeAOT/trimming-safe way. This involves accepting source-generated artifacts, but we don't yet know the precise shape. An abstract base class would allow us to add this later once a full design is clear.
  • We also have some (minor) opportunities for default implementations, e.g. CreateCollectionIfExists could be implemented over an existence check and a creation.
  • The original MEVD design was based around interfaces since some connector implementations implemented the interface multiple times. For example, QdrantVectorStoreRecordCollection implemented IVectorStoreRecordCollection twice, once for Guid keys and once for ulong keys. We since switched to a different approach, where QdrantVectorStoreRecordCollection itself is generic over the key, and an invalid key causes a runtime error instead. This was done for dynamic support (object key), but also improved the dev experience since the multiple interfaces required one of them to be an explicit interface implementation.
@roji roji added Build Features planned for next Build conference msft.ext.vectordata Related to Microsoft.Extensions.VectorData labels Apr 28, 2025
@roji roji added the .NET Issue or Pull requests regarding .NET code label Apr 28, 2025
@roji roji moved this to Backlog: Planned in Semantic Kernel Apr 28, 2025
@github-actions github-actions bot changed the title [MEVD] Switch IVectorStore and IVectorStoreRecordCollection from interfaces to abstract base classes .Net: [MEVD] Switch IVectorStore and IVectorStoreRecordCollection from interfaces to abstract base classes Apr 28, 2025
@roji roji assigned roji and unassigned westey-m May 2, 2025
roji added a commit to roji/semantic-kernel that referenced this issue May 2, 2025
roji added a commit to roji/semantic-kernel that referenced this issue May 2, 2025
roji added a commit that referenced this issue May 2, 2025
@roji roji moved this from Backlog: Planned to Sprint: Done in Semantic Kernel May 2, 2025
@roji roji closed this as completed May 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Build Features planned for next Build conference msft.ext.vectordata Related to Microsoft.Extensions.VectorData .NET Issue or Pull requests regarding .NET code
Projects
Archived in project
Development

No branches or pull requests

3 participants