redis/redis-vl-python

Add Index Alias management capabilities

Opened this issue · 4 comments

pierrelambert commented

The Alias capability of Indexes with ft.aliasadd, ft.aliasdel, FT.ALIASUPDATE permits agility in making index and apps evolving.
Would be nice to be able to handle this at SearchIndex level directly.

tylerhutcherson commented

@pierrelambert 100% Agreed - this is planned for the 0.3.0 release. Though it gets tricky without the ability to list which aliases are used per index.

Ideally the index alias would be a schema property like this:

index:
  name: users_v1
  prefix: user
  alias: users

fields:
    - name: user
      type: tag
    - name: credit_score
      type: tag

So then the alias would get added transparently as they call index.create(...)

And then a new command to update the alias:

index.update_alias("new_alias_name")

However, given we can't trace the state of the index<>alias relationships... this is pretty much impossible without footguns all over the place.

@bsbodden curious on your take?

pierrelambert commented

Define / Set an alias to an index is must have.
Change the index an alias is referring to (FT.ALIASUPDATE) is must have too

bsbodden commented

I agree with @pierrelambert that this is a must have for prod environments, since the index to alias relationship is a one-to-many we could:

  • take a list of strings under aliases or a single string under alias
  • We can use FT.INFO alias to determine if the alias exists and also use index_name to verify that it is attached to the current index
  • Keep/manage our own per-index Redis SET of aliases (something like [index_name]_ALIASES) until a command to retrieve aliases is provided (FT._LIST_ALIASES index)
  • Using a set this way is a very common pattern in Redis libraries, we just need to make sure we clean up after ourselves when/if the index is deleted
tylerhutcherson commented

I like this approach. I’ve been hesitant to create extra “metadata” generated by the library… but I think I agree that usability and functionality is most important here. We need alias support for sure.

I’ll start working on a more detailed write up for this.