Added versioning support for DynamoDB#6191
Open
rpathade wants to merge 1 commit intofeast-dev:masterfrom
Open
Conversation
Signed-off-by: RutujaPathade <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it
Closes #6163
Feature view versioning was introduced in #6101, but version-qualified feature references (e.g.
driver_stats@v2:trips_today) only worked with the SQLite online store. All other online stores raised
VersionedOnlineReadNotSupported when a versioned ref was used.
This PR adds versioned read/write support to the DynamoDB online store, following the same pattern as the
SQLite reference implementation:
to the DynamoDB table name (e.g. project.driver_stats_v2), routing materialization to the correct versioned
table
online_read is called; _get_table_name picks this up and routes to the correct table. projection.version_tag
takes priority over current_version_number so explicit version requests are always honoured
both sync and async read paths
All existing read/write/update/teardown methods are covered by the single change to _get_table_name since
every method routes through it.
Which issue(s) this PR fixes
Part of #2728
Checks
Testing Strategy
priority, current_version_number fallback, version 0 edge case, no version info, custom template
across v1/v2 isolation, fallback behaviour, and missing entity handling
Misc
The version suffix is composed before the table_name_template is applied, so custom table_name_template
values (e.g. "{project}__{table_name}") continue to work correctly with versioning enabled.