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: add WITH clause and QUERY_ID property to INSERT INTO statements #6553

Merged
merged 3 commits into from
Nov 6, 2020

Conversation

spena
Copy link
Member

@spena spena commented Oct 30, 2020

Description

Implements #6533

Add a WITH clause to the INSERT statement to allow users specify a custom query QUERY_ID.
For intance:

ksql> insert into s1 with (query_id='my_insert_id') select * from s1;

 Message                            
------------------------------------
 Created query with ID MY_INSERT_ID 
------------------------------------

ksql> show queries;

 Query ID     | Query Type | Status    | Sink Name | Sink Kafka Topic | Query String                                              
----------------------------------------------------------------------------------------------------------------------------------
 MY_INSERT_ID | PERSISTENT | RUNNING:1 | S1        | t1               | insert into s1 with (query_id='my_insert_id') select * from s1; 
----------------------------------------------------------------------------------------------------------------------------------
For detailed information on a Query run: EXPLAIN <Query ID>;

ksql> terminate my_insert_id;

 Message           
-------------------
 Query terminated. 
-------------------

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 #")

@spena spena added this to the 0.15.0 milestone Oct 30, 2020
@spena spena requested a review from a team October 30, 2020 20:11
* 'With Clause' properties for 'INSERT INTO' statements.
*/
public final class InsertIntoConfigs {
public static final String QUERY_ID_PROPERTY = "ID";
Copy link
Member Author

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')

Copy link
Contributor

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

@spena spena force-pushed the insert_with_clause branch from e2f2f6e to 0c24324 Compare November 2, 2020 16:42
Copy link
Contributor

@agavra agavra left a 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";
Copy link
Contributor

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"
Copy link
Contributor

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?

Copy link
Member Author

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) {
Copy link
Contributor

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

Copy link
Member Author

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?

Copy link
Contributor

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()) {
Copy link
Contributor

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)

Copy link
Member Author

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
Copy link
Contributor

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

Copy link
Member Author

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() {
Copy link
Contributor

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?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@spena spena force-pushed the insert_with_clause branch from 0c24324 to 3b66921 Compare November 4, 2020 20:20
@spena
Copy link
Member Author

spena commented Nov 4, 2020

Thanks @agavra. I changed the ID to QUERY_ID. I liked it better too.

@spena spena force-pushed the insert_with_clause branch 2 times, most recently from f9d7d70 to 66ce5e7 Compare November 5, 2020 21:49
spena added 3 commits November 6, 2020 08:51
- Change ID to QUERY_ID
- Better comments in InsertIntoConfigs
- Check if new QueryId already exists
- Add RecoverTest test
@spena spena force-pushed the insert_with_clause branch from 66ce5e7 to 075bc02 Compare November 6, 2020 14:52
@spena spena changed the title feat: add WITH clause and ID property to INSERT INTO statements feat: add WITH clause and QUERY_ID property to INSERT INTO statements Nov 6, 2020
@spena spena merged commit a344114 into confluentinc:master Nov 6, 2020
@spena spena deleted the insert_with_clause branch November 6, 2020 16:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants