Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix: misuse of props and options in
CREATE SOURCE
#13762New 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
fix: misuse of props and options in
CREATE SOURCE
#13762Changes from 10 commits
08ffe34
d46b94c
a92d67f
08bda7f
da9ce5c
1295a58
b19fe0b
0d28278
f9092b9
a914777
cae3290
fbb0aad
f69c6e8
a5d73e8
2e0fdad
c4caa53
dfccb7d
857cd6f
bef1e78
3721341
eae190d
e28db0f
213f6b5
b70b1d8
3135e9f
9f817c3
185a590
47e6ff3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 might need to rename the type alias now... 🥵
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.
Besides,
properties
andoptions
are not meaningful names. Can we change them to sth likewith_options
andencode_format_options
/row_options
?Also in all other places, including proto
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 about
with_properties
androw_options
?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 most of fields in
option
are related to parser behavior, I preferencode_option
orparser_option
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 have been calling them
format options
for sink 😂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.
parser_options
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.
Wait a minute, the syntax seems to be
FORMAT ... ENCODE ... (...)
, so at least it should beformat_encode_options
🤣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.
From the syntax, the options indeed look like it's for
ENCODE
🤔.From the parser's definition it seems to be called
row_options
, so I guess this is what it should be like when it was designed (and not only forENCODE
). So might worth asking @st1page what's the best name for it.risingwave/src/sqlparser/src/ast/statement.rs
Lines 338 to 342 in b5c3f5d
I'm wondering whether
parser_options
will be confusing to users. We need to consider this in the error messages (maybe also syntax reference, but currently it also doesn't have a 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.
c.c. @tabVersion
I think it is the historical reason...
format_encode_options
LGTM.Btw, we might need some options in the
KEY ENCODE
in the future.or maybe this syntax
Considering the unknown part of the other options... I think
format_encode_options
is the most specific and clear 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.
+1 for
format_encode_options
for KEY ENCODE, I think it is ok to add some fields in the options because the clause is optional in SQL and we don't expect it as strong as the value part.
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.
BTW, should we consider backward compatibility 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.
For now, legacy codes that try to find keys of
format_encode_options
inwith_properties
are identified and corrected. So unmergingformat_encode_options
fromwith_properties
will not result in key-not-found-like errors. Is this thebackward compatibility
you suggested?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.
IMO the most important thing is: already created source can still work. It seems compute node doesn't use
format_encode_options
at all and thus not broken? (I'm not very sure. Correct me if I'm wrong.)Besides is the semantics change on the frontend. I'm still not sure whether sth is changed (i.e., can work previously, but can't work now, and vice versa). But actually that's acceptable to me...
Glad to hear others' thoughts about detailed backward compatibility concerns. @BugenZhao zkss
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.
Yes!
Also the meta service part: does it handle the cases that the new fields do not exist?
TBH, I'm not that familiar with the connector part. 🤣 Practice is the sole criterion for testing truth.
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 just added a backwards-compat test for invalid WITH options #13824. Can we or do we need to add similar stuff for this 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.
Do you mean that, for example, a user creates a source using RW 1.4, and then upgrades to RW 1.5. So codes in RW 1.5 should recognize it as legacy source and try to find option keys in properties. Is this hot-update issue you concerned?
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.
Yes
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.
Got it. We do need to add more codes to handle this issue.
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.
FYI 😇 this is my solution for rejecting unknown WITH
2e39b51#diff-a80dd5cfb3d2b493a15182ad5c447741b10820fa16b8eea2719b9c0ae6f003a4R415-R418