You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add feature view versioning support to Elasticsearch online store #6172
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:
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})
Read path: Route version-qualified lookups to the correct versioned table/key namespace
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.
#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.
Activity
ruslan-shaydullin commentedon Aug 25, 2026
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 usecompute_versioned_name()for versioned indexes such asdriver_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
_vNindexes?Once the intended behavior is confirmed, I'll add unit coverage and a real Elasticsearch testcontainers test covering v1/v2 isolation and cleanup.
alekseevpavel04 commentedon Aug 25, 2026
#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_namebehind one helper; the name is unchangedwhen versioning is off and when the resolved version is 0, so existing indices do
not move; and
ElasticSearchOnlineStoreis added toOnlineStore._is_versioned_read_supported— without that second half a versionedread is refused however the indices are named, which is easy to miss because it
lives in another file.
teardownremoves the resolved version only, followingsqlite.py, which is your third question; I took the same answer you suggested,but it is the maintainers' to confirm.
The
online_readbehaviour you spotted is not in it. Hits come back inElasticsearch'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.