Skip to content

Add feature view versioning support to Elasticsearch online store #6172

Open

Description

@franciscojavierarceo

Summary

Add versioned feature view read/write support to the Elasticsearch online store, so that version-qualified feature references (e.g., driver_stats@v2:trips_today) resolve to the correct versioned data.

Context

Feature view versioning was introduced in #6101. Currently, only the SQLite online store supports versioned reads/writes. All other online stores raise VersionedOnlineReadNotSupported when a versioned ref is used.

The implementation pattern (see sqlite.py for reference) involves:

  1. Write path: When enable_online_feature_view_versioning is enabled, materialize data into a version-specific table/key namespace (e.g., {project}_{fv_name}_v{version})
  2. Read path: Route version-qualified lookups to the correct versioned table/key namespace

Reference implementation

  • SQLite online store: sdk/python/feast/infra/online_stores/sqlite.py
  • Store file: sdk/python/feast/infra/online_stores/elasticsearch_online_store/elasticsearch.py

Related

Part of #2728

Activity

  1. ruslan-shaydullin commented on Aug 25, 2026

    @ruslan-shaydullin

    Hi, I'd like to work on the Elasticsearch part of this issue.

    I checked the current implementation and found a couple of details I'd like to confirm before starting. Elasticsearch currently uses index names such as driver_stats, so I would preserve that behavior when versioning is disabled and use compute_versioned_name() for versioned indexes such as driver_stats_v1.

    The current online_read() also returns only the Elasticsearch hits, in Elasticsearch's order, rather than aligning results with the requested entity keys and representing misses. Is it okay to include a bounded fix for that as part of this issue? Should the query also explicitly select the latest row for each entity, or is result alignment enough here?

    For teardown, should it remove only the requested version, or the base index together with all matching _vN indexes?

    Once the intended behavior is confirmed, I'll add unit coverage and a real Elasticsearch testcontainers test covering v1/v2 isolation and cleanup.

  2. alekseevpavel04 commented on Aug 25, 2026

    @alekseevpavel04

    #6781 is open for the Elasticsearch part. I read this thread before starting and
    not again before opening it, so I missed your comment by about an hour — flagging
    that now rather than after you have spent an evening on the same change.

    What it does, so the overlap is easy to judge: the nine places that name an index
    all go through compute_versioned_name behind one helper; the name is unchanged
    when versioning is off and when the resolved version is 0, so existing indices do
    not move; and ElasticSearchOnlineStore is added to
    OnlineStore._is_versioned_read_supported — without that second half a versioned
    read is refused however the indices are named, which is easy to miss because it
    lives in another file. teardown removes the resolved version only, following
    sqlite.py, which is your third question; I took the same answer you suggested,
    but it is the maintainers' to confirm.

    The online_read behaviour you spotted is not in it. Hits come back in
    Elasticsearch's order with no alignment to the requested entity keys and no
    representation of misses — that is a real bug, separate from versioning, and it
    is your find.

    If the maintainers would rather you take this whole, say so and I will close mine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions