-
-
Notifications
You must be signed in to change notification settings - Fork 16
Refactor ColumnDefinitionParser
#466
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
base: master
Are you sure you want to change the base?
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #466 +/- ##
============================================
+ Coverage 96.64% 96.71% +0.06%
+ Complexity 409 407 -2
============================================
Files 66 66
Lines 1192 1216 +24
============================================
+ Hits 1152 1176 +24
Misses 40 40 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
Pull request overview
This PR refactors the ColumnDefinitionParser class to extend from AbstractColumnDefinitionParser instead of directly implementing the parsing logic. The refactoring delegates core parsing logic to the parent class while maintaining PostgreSQL-specific type handling through the new parseTypeParams() method.
- Simplified
parseDefinition()method to return raw parsed components instead of fully processed info - Introduced
parseTypeParams()using match expressions to handle PostgreSQL-specific type parameter parsing - Removed unnecessary imports and psalm-suppress annotation
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Column/ColumnDefinitionParser.php | Refactored to extend AbstractColumnDefinitionParser, simplified parsing methods, and added PostgreSQL-specific type parameter handling via match expression |
| tests/ArrayParserTest.php | Removed unnecessary @psalm-suppress PropertyNotSetInConstructor annotation |
| CHANGELOG.md | Added entry documenting the breaking change refactor |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| $typeDetails = $matches[4] ?? $matches[2] ?? ''; | ||
|
|
||
| if ($typeDetails !== '') { | ||
| if ($type === 'enum') { |
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.
'enum' here and in other drivers should be an abstract type and must be parsable.
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.
Enum couldn't use in column definition directly.
| 'varbit', | ||
| 'varchar' => $this->parseSizeInfo($params), | ||
| default => [], | ||
| }; |
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.
Abstract, pseudo, or user-defined types must also be parsable.
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.
Why need to parse abstract and pseudo type? What case when this is needed?
Isn't custom types are support parameters?
Related to yiisoft/db#1108