Using the IMemoryStore Interface and DevExpress XPO ORM to Implement a Custom Memory Store for Semantic Kernel

by Joche Ojeda | Sep 4, 2024 | A.I, Semantic Kernel, XPO

In today’s AI-driven world, the ability to quickly and efficiently store, retrieve, and manage data is crucial for developing sophisticated applications. One tool that helps facilitate this is the Semantic Kernel, a lightweight, open-source development kit designed for integrating AI models into C#, Python, or Java applications. It enables rapid enterprise-grade solutions by serving as an effective middleware.

One of the key concepts in Semantic Kernel is memory—a collection of records, each containing a timestamp, metadata, embeddings, and a key. These memory records can be stored in various ways, depending on how you implement the interfaces. This flexibility allows you to define the storage mechanism, which means you can choose any database solution that suits your needs.

In this blog post, we’ll walk through how to use the IMemoryStore interface in Semantic Kernel and implement a custom memory store using DevExpress XPO, an ORM (Object-Relational Mapping) tool that can interact with over 14 database engines with a single codebase.

Why Use DevExpress XPO ORM?

DevExpress XPO is a powerful, free-to-use ORM created by DevExpress that abstracts the complexities of database interactions. It supports a wide range of database engines such as SQL Server, MySQL, SQLite, Oracle, and many others, allowing you to write database-independent code. This is particularly helpful when dealing with a distributed or multi-environment system where different databases might be used.

By using XPO, we can seamlessly create, update, and manage memory records in various databases, making our application more flexible and scalable.

Implementing a Custom Memory Store with DevExpress XPO

To integrate XPO with Semantic Kernel’s memory management, we’ll implement a custom memory store by defining a database entry class and a database interaction class. Then, we’ll complete the process by implementing the IMemoryStore interface.

Step 1: Define a Database Entry Class

Our first step is to create a class that represents the memory record. In this case, we’ll define an XpoDatabaseEntry class that maps to a database table where memory records are stored.

public class XpoDatabaseEntry : XPLiteObject {
    private string _oid;
    private string _collection;
    private string _timestamp;
    private string _embeddingString;
    private string _metadataString;
    private string _key;

    [Key(false)]
    public string Oid { get; set; }
    public string Key { get; set; }
    public string MetadataString { get; set; }
    public string EmbeddingString { get; set; }
    public string Timestamp { get; set; }
    public string Collection { get; set; }

    protected override void OnSaving() {
        if (this.Session.IsNewObject(this)) {
            this.Oid = Guid.NewGuid().ToString();
        }
        base.OnSaving();
    }
}

This class extends XPLiteObject from the XPO library, which provides methods to manage the record lifecycle within the database.

Step 2: Create a Database Interaction Class

Next, we’ll define an XpoDatabase class to abstract the interaction with the data store. This class provides methods for creating tables, inserting, updating, and querying records.

internal sealed class XpoDatabase {
    public Task CreateTableAsync(IDataLayer conn) {
        using (Session session = new(conn)) {
            session.UpdateSchema(new[] { typeof(XpoDatabaseEntry).Assembly });
            session.CreateObjectTypeRecords(new[] { typeof(XpoDatabaseEntry).Assembly });
        }
        return Task.CompletedTask;
    }

    // Other database operations such as CreateCollectionAsync, InsertOrIgnoreAsync, etc.
}

This class acts as a bridge between Semantic Kernel and the database, allowing us to manage memory entries without having to write complex SQL queries.

Step 3: Implement the IMemoryStore Interface

Finally, we implement the IMemoryStore interface, which is responsible for defining how the memory store behaves. This includes methods like UpsertAsync, GetAsync, and DeleteCollectionAsync.

public class XpoMemoryStore : IMemoryStore, IDisposable {
    public static async Task ConnectAsync(string connectionString) {
        var memoryStore = new XpoMemoryStore(connectionString);
        await memoryStore._dbConnector.CreateTableAsync(memoryStore._dataLayer).ConfigureAwait(false);
        return memoryStore;
    }

    public async Task CreateCollectionAsync(string collectionName) {
        await this._dbConnector.CreateCollectionAsync(this._dataLayer, collectionName).ConfigureAwait(false);
    }

    // Other methods for interacting with memory records
}

The XpoMemoryStore class takes advantage of XPO’s ORM features, making it easy to create collections, store and retrieve memory records, and perform batch operations. Since Semantic Kernel doesn’t care where memory records are stored as long as the interfaces are correctly implemented, you can now store your memory records in any of the databases supported by XPO.

Advantages of Using XPO with Semantic Kernel

• Database Independence: You can switch between multiple databases without changing your codebase.
• Scalability: XPO’s ability to manage complex relationships and large datasets makes it ideal for enterprise-grade solutions.
• ORM Abstraction: With XPO, you avoid writing SQL queries and focus on high-level operations like creating and updating objects.

Conclusion

In this blog post, we’ve demonstrated how to integrate DevExpress XPO ORM with the Semantic Kernel using the IMemoryStore interface. This approach allows you to store AI-driven memory records in a wide variety of databases while maintaining a flexible, scalable architecture.

In future posts, we’ll explore specific use cases and how you can leverage this memory store in real-world applications. For the complete implementation, you can check out my GitHub fork.

Stay tuned for more insights and examples!