Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Streaming aggregate cursor now requires 4.1.9.0 or later for continuation deserialization #3246

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

alecgrieser
Copy link
Collaborator

@alecgrieser alecgrieser commented Mar 13, 2025

This cleans up the StreamingAggregateCursor and its helper classes to remove the createDefaultIfEmpty option. We'd been carrying that option around as we introduced that field in #3092 and wanted to preserve behavior when upgrading from older versions. The intention had been that all new plans would set the option starting in 4.1, but a bug (fixed in #3211; see #3096) means that we didn't actually enable it until 4.1.9.0. That means that after this change, we'd require 4.1.9.0 or newer in order to safely continue these queries. In theory, we could wait with this change, but 4.1.9.0 has enough fixes that I actually think our recommendation should be that anyone upgrading from 4.0 or below go straight to 4.1.9.0, and then they can proceed safely to a newer version with this change.

I was able to validate that this change is compatible with 4.1.9.0 via the cross-version tests run during PRB. When I ran the full mixed mode tests with the aggregate-index-tests.yamsql, I found that only 4.1.9.0 worked, which is expected.

This resolves #3107.

…tion deserialization

This cleans up the `StreamingAggregateCursor` and its helper classes to remove the `createDefaultIfEmpty` option. We'd been carrying that option around as we introduced that field in FoundationDB#3092 and wanted to preserve behavior when upgrading from older versions. The intention had been that all new plans would set the option starting in 4.1, but a bug (fixed in FoundationDB#3211; see FoundationDB#3096) means that we didn't actually enable it until 4.1.9.0. That means that after this change, we'd require 4.1.9.0 or newer in order to safely continue these queries. In theory, we could wait with this change, but 4.1.9.0 has enough fixes that I actually think our recommendation should be that anyone upgrading from 4.0 or below go straight to 4.1.9.0, and then they can proceed safely to a newer version with this change.

I was able to validate that this change is compatible with 4.1.9.0 via the cross-version tests run during PRB. When I ran the full mixed mode tests with the `aggregate-index-tests.yamsql`, I found that only 4.1.9.0 worked, which is expected.

This resolves FoundationDB#3092.
@alecgrieser alecgrieser added the breaking change Changes that are not backwards compatible label Mar 13, 2025
@alecgrieser alecgrieser added this to the 4.2 milestone Mar 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Changes that are not backwards compatible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove versioning shim code introduced in #3092
1 participant