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

feat: allow for only Gen 1 create or replace queries with server level configs via rest api, bars all gen 2 queries #8711

Merged
merged 2 commits into from Feb 4, 2022

Conversation

wcarlson5
Copy link
Member

This forces any queries coming into the shared runtimes to not have overridden the server level props. If the query will not be going into the new shared runtimes (i.e. is a create or replace of an old query) it will not be held to those standards.

Testing done

Describe the testing strategy. Unit and integration tests are expected for any behavior changes.

Reviewer checklist

  • Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
  • Ensure relevant issues are linked (description should include text like "Fixes #")

@wcarlson5 wcarlson5 requested a review from a team as a code owner February 3, 2022 00:33
@wcarlson5
Copy link
Member Author

@rodesai This is the check we talked about that should allow for server level configs to be set for old queries during a create or replace. But it will make sure that any queries going into the new runtimes will fail with a useful message

@wcarlson5
Copy link
Member Author

When testing this PR I found an issue with recovering replaced gen 1 queries that I fixed here #8713

I will hold off merging until that is merged

Copy link
Contributor

@guozhangwang guozhangwang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @wcarlson5 the title and the description and the content of the PR seems to be indicating a bit different scopes: from the title and the content of the PR, we are only checking against the create or replace query stmt to not have any server level config overrides; whereas in your PR description you mentioned This forces any queries coming into the shared runtimes.. could you modify it to be consistent and hence easy to understand fo other readers?

Otherwise, LGTM!

@wcarlson5 wcarlson5 changed the title feat: allow for only old queries to create or replace with server level configs via rest api feat: allow for only Gen 1 to create or replace with server level configs via rest api Feb 4, 2022
@wcarlson5 wcarlson5 changed the title feat: allow for only Gen 1 to create or replace with server level configs via rest api feat: allow for only Gen 1 create or replace queries with server level configs via rest api, bars all gen 2 queries Feb 4, 2022
@wcarlson5 wcarlson5 merged commit 4413f85 into confluentinc:master Feb 4, 2022
@wcarlson5 wcarlson5 deleted the limit_query_configs branch February 4, 2022 04:17
@@ -272,6 +273,7 @@ public PersistentQueryMetadata createOrReplacePersistentQuery(

if (sharedRuntimeId.isPresent() && (oldQuery == null
|| oldQuery instanceof BinPackedPersistentQueryMetadataImpl)) {
throwOnNonQueryLevelConfigs(config.getOverrides());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late feedback here. We should only do validation like this in the validation phase of executing a statement. Otherwise we might change the validation later on in a way that causes us to fail statements we've already accepted. The pattern for doing that is to do this type of validation in the sandbox instance only - can you make that change in a follow-up?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#8722 sure

Those configs will be ignored but it won't mean there is a record in the cmd topic that will cause it to fail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants