-
Notifications
You must be signed in to change notification settings - Fork 1k
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: add WITH clause and QUERY_ID property to INSERT INTO statements #6553
Conversation
* 'With Clause' properties for 'INSERT INTO' statements. | ||
*/ | ||
public final class InsertIntoConfigs { | ||
public static final String QUERY_ID_PROPERTY = "ID"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose ID
as the best name for this property. However, if it is confusing with the ID
keyword in the schema (i.e. ID id int
), then we can consider these options.
with (id = 'my_id')
with (query_id = 'my_id')
with (name = 'my_id')
with (alias = 'my_id')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think originally I liked id
, but now my preference is query_id
😂 it gives a little bit more clarity into what exactly it is. cc @colinhicks
e2f2f6e
to
0c24324
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Some minor comments inline
* 'With Clause' properties for 'INSERT INTO' statements. | ||
*/ | ||
public final class InsertIntoConfigs { | ||
public static final String QUERY_ID_PROPERTY = "ID"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think originally I liked id
, but now my preference is query_id
😂 it gives a little bit more clarity into what exactly it is. cc @colinhicks
ConfigDef.Type.STRING, | ||
null, | ||
ConfigDef.Importance.LOW, | ||
"Custom query ID to use for INSERT INTO queries" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's have some more detailed documentation here. What is it used for? what happens if it isn't supplied? what are valid values? is it case insensitive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
|
||
private QueryIdUtil() { | ||
} | ||
|
||
private static void validateWithQueryId(final String queryId) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should make this a ConfigDef.Validator
and validate it as part of the config def
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I initially thought of this, but I decided to do the validation in the QueryIdUtil
to make sure that whoever wants to use that class, then they pass the right QueryID string. I don't think nobody else will use it, but I think is a better design as the buildId
is the one will check IDs are correct.
Unless you have another reason to use the Validator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that makes sense
final boolean createOrReplaceEnabled) { | ||
final boolean createOrReplaceEnabled, | ||
final Optional<String> withQueryId) { | ||
if (withQueryId.isPresent()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we also validate to make sure they don't register the same queryID twice? (please add a test for this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. I added the validation in the EngineExecutor
'cause is the one that knows about IDs by calling the engineContext.getPersistentQuery
.
@@ -33,4 +35,11 @@ | |||
* @return the sink info. | |||
*/ | |||
Sink getSink(); | |||
|
|||
/** | |||
* Return an optional query ID if specified by the user |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's specify here that this is only intended to be used by INSERT INTO
- that way we can remove it when we remove INSERT INTO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@@ -347,6 +347,31 @@ public void shouldThrowWhenInsertIntoSchemaDoesNotMatch() { | |||
is("insert into bar select orderTime, itemid from orders;"))); | |||
} | |||
|
|||
@Test | |||
public void shouldExecuteInsertIntoWithCustomQueryId() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a test in RecoveryTest
to make sure we can recover create/terminate with custom query IDs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
0c24324
to
3b66921
Compare
Thanks @agavra. I changed the |
f9d7d70
to
66ce5e7
Compare
- Change ID to QUERY_ID - Better comments in InsertIntoConfigs - Check if new QueryId already exists - Add RecoverTest test
66ce5e7
to
075bc02
Compare
Description
Implements #6533
Add a
WITH
clause to theINSERT
statement to allow users specify a custom query QUERY_ID.For intance:
Testing done
Describe the testing strategy. Unit and integration tests are expected for any behavior changes.
Reviewer checklist