-
Notifications
You must be signed in to change notification settings - Fork 704
feat(sink): support create sink as query #6648
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
Conversation
| let user_core = &mut core.user; | ||
| database_core.ensure_database_id(sink.database_id)?; | ||
| database_core.ensure_schema_id(sink.schema_id)?; | ||
| database_core.ensure_table_id(sink.associated_table_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 suggest to check whether dependent_relations exists here.
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.
None of the other streaming jobs did this. Maybe do it in a separate pr.
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.
All of other streaming jobs do this. You can take a look at start_create_table_procedure. Some functions doesn't check dependent_relations, because we can find all the dependents without dependent_relations variable.
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.
Oh I see. Acctually create_index did't do this. Should I also add the check for it?
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.
No. Index only depends on its primary table, so we just check whether primary_table_id exists.
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.
So the dependent_relations should contains 1 and only 1 item that is the primary_table_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.
Yeah, index's dependent_relations only contains primary_table_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.
Then let's add an assert here!
| // If colume names not specified, use the name in materialized view. | ||
| let col_names = get_column_names(&bound, session, stmt.columns)?.or(sink_col_names); | ||
|
|
||
| let sink_name = Binder::resolve_sink_name(stmt.sink_name)?; |
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.
Help to remove resolve_sink_name. Thanks
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.
maybe no need to do that. still not sure if it will be used later
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.
This resolve_sink_name was used to ensure that the sink and the corresponding table are in the same schema. I think after your PR, we don't need this constraint anymore. I think we support create sink xxx as select * from a.yyy join b.zzz on ... now and we have no idea whether xxx's schema is a or b
Codecov Report
@@ Coverage Diff @@
## main #6648 +/- ##
==========================================
- Coverage 73.95% 73.30% -0.65%
==========================================
Files 980 1012 +32
Lines 159120 162132 +3012
==========================================
+ Hits 117671 118845 +1174
- Misses 41449 43287 +1838
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
| CREATE SINK s4 AS select mv4.v1 as v1, mv4.v2 as v2 from mv4 WITH ( | ||
| connector = 'mysql', | ||
| endpoint = '127.0.0.1:3306', | ||
| user = 'root', | ||
| database = 'test', | ||
| table = 't4' | ||
| ); |
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 are deprecating the built-in mysql connector soon. please use jdbc connector here.
blocked by #6631
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.
How and when should I swith to jdbc?
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.
BugenZhao
left a comment
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.
Generally LGTM! Good work!
st1page
left a comment
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.
The Frontend part LGTM. But this PR modifies so many components, PTAL again 😿 c.c. @BugenZhao @yezizp2012 @HuaHuaY
HuaHuaY
left a comment
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!
yezizp2012
left a comment
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.
The meta part LGTM, great job!
I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
Checklist
./risedev check(or alias,./risedev c)Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Release note
support
CREATE SINK sink_name AS select xxx from TABLE / MATERIALIZED VIEW / SOURCE WITH(connector = 'xxx')Refer to a related PR or issue link (optional)