-
Notifications
You must be signed in to change notification settings - Fork 85
Description
Problem: Our company is using Redis.OM in a load balanced environment where we periodically bring down an app node, deploy the next version of our ASP.NET Core application, on startup drop/create the index if the schema has changed, but we incur that known period of downtime where the index is recreating and queries return no data.
What I'm aware we could do to work around it:
- Blue/green deployments
- Fair bit of changes for our on-prem deployment envs
- Passing a fake of
System.Typein with a dynamically modifiedDocumentattribute to change theIndexName- This does work but it's quite the hack
- Fork the repo
- This repo would be lower maintenance, but we like to not :)
Proposal: Without going down the rabbit hole of adding official migration support, which I see based on past issues the maintainers don't currently want to support given demand.. Perhaps just an overload to the RediSearchCommands.CreateIndex / CreateIndexAsync commands to allow more advanced users the ability to create the index aliased.
public static async Task<bool> CreateIndexAsync(this IRedisConnection connection, Type type, string indexNameOverride)..so that on app startup, we can in our application's code:
- Create a new versioned index (
person-idx_20250612023945postfixed with a timestamp) - Add an alias
person-idx(or update it if it exists already) to point to the new index - Continue to block the startup of the node and therefore the deployment of the other nodes until the index is done with the initial scan
This would allow us to do no-downtime deployments without adding full migration support to redis-om-dotnet.
Is this something the maintainers would be open to our contribution for this or an alternative contribution?