-
Notifications
You must be signed in to change notification settings - Fork 490
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
lexer: replace version comments with feature-ids mechanism #777
Conversation
Codecov Report
@@ Coverage Diff @@
## master #777 +/- ##
==========================================
+ Coverage 78.05% 78.11% +0.05%
==========================================
Files 40 40
Lines 14669 14703 +34
==========================================
+ Hits 11450 11485 +35
+ Misses 2537 2536 -1
Partials 682 682 |
The parser should not care about the detail of what If we change to |
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.
Rest LGTM
lexer.go
Outdated
|
||
func (s *Scanner) scanFeatureIDs() (featureIDs []string) { | ||
pos := s.r.pos() | ||
const init, expectAlpha, alpha = 0, 1, 2 |
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.
state name should more clear?
@tiancaiamao Do you have any suggestions to deal with the problem mentioned in description? How about putting the |
The idea sounds good. I just have concerns about the compatibility issue.
Much better. |
IMO, it doesn't affect rolling updates. Currently, only
|
in the worst case we could support both |
If none of our users is actually using |
if commentVersion <= CommentCodeCurrentVersion { | ||
// in '/*T!', try to match the pattern '/*T![feature1,feature2,...]'. | ||
features := s.scanFeatureIDs() | ||
if SpecialCommentsController.ContainsAll(features) { | ||
s.inBangComment = true | ||
return s.scan() | ||
} |
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.
What happens if the feature id is not included in the list?
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.
It will parse it as normal comments. For now, the behavior is:
FeatureMap: {"xxx", "yyy"}
/*T![xxx,yyy] part_of_sql */ # all the feature ids matched
/*T![xxx,zzz] part_of_sql */ # one feature id mismatched
/*T![xxx part_of_sql */ # no feature id detected
/*T!part_of_sql */ # no feature id detected
are equivalant to
part_of_sql
[xxx part_of_sql
part_of_sql
respectively.
LGTM |
This PR should be merged together with pingcap/tidb#15412. |
* lexer: replace version comments with feature-ids mechanism * tests: retain the original version digit test * fix scanVersionDigits * add SpecialCommentsController to decide what comments can be parsed * only ignore comments with unsupported feature-id * remove debug log
* lexer: replace version comments with feature-ids mechanism * tests: retain the original version digit test * fix scanVersionDigits * add SpecialCommentsController to decide what comments can be parsed * only ignore comments with unsupported feature-id * remove debug log
* lexer: replace version comments with feature-ids mechanism * tests: retain the original version digit test * fix scanVersionDigits * add SpecialCommentsController to decide what comments can be parsed * only ignore comments with unsupported feature-id * remove debug log
* lexer: replace version comments with feature-ids mechanism * tests: retain the original version digit test * fix scanVersionDigits * add SpecialCommentsController to decide what comments can be parsed * only ignore comments with unsupported feature-id * remove debug log
What problem does this PR solve?
Executable special comments like
/*T!40000 xxx */
are not suitable for TiDB. Due to the nature of branch-release, new features can be cherry-picked to different major versions TiDB. As a result, a TiDB with a higher version may not support the features in a TiDB with a lower version.To solve this problem, this PR gives a mechanism to manage the features that need to support forward compatibility:
feature-id
.featureMap
, which contains a set of currently supported feature-ids./*T![feature_id] xxx */
is used to wrap the key part during logical synchronization.feature_id
infeatureMap
./*T![feature_id1,feature_id2,...] xxx */
. It can only be parsed if all feature IDs in the comment can be found in thefeatureMap
.What is changed and how it works?
Add
scanFeatureIDs()
to scan feature ids in special comments.Check List
Tests
Code changes
Side effects
Related changes