-
Notifications
You must be signed in to change notification settings - Fork 102
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
Rework auto begin/commit/rollback transaction during query lifetime #4674
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
std::vector<PropertyDefinition> Binder::bindPropertyDefinitions( | ||
const std::vector<ParsedPropertyDefinition>& parsedDefinitions, const std::string& tableName) { | ||
std::vector<PropertyDefinition> definitions; | ||
for (auto& parsedDefinition : parsedDefinitions) { | ||
auto type = LogicalType::convertFromString(parsedDefinition.getType(), clientContext); | ||
// For default null value, we may need to resolve its data type, as its type may not be | ||
// resolved during parsing and thus may be ANY. | ||
tryResolvingDataTypeForDefaultNull(parsedDefinition, type); |
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.
Cannot this be handled with implicitCast in l79? I don't think this is a good design.
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 actually don't know. Let me give a try, if implicitCast can handle this, it would be great.
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 cannot directly use implicitCast here because the boundExpr—after binding and implicit casting—is not actually utilized in PropertyDefinition. Instead, PropertyDefinition continues to hold the parsed expression, which is not cast.
I believe the current approach of storing ParsedExpression in PropertyDefinition is not well designed. This method essentially discards the results of binding and casting (which are only used for validation) and re-binds the default expression whenever it is needed. Will discuss with @acquamarin too and see if I should open an issue on this.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4674 +/- ##
=======================================
Coverage 86.39% 86.39%
=======================================
Files 1373 1373
Lines 58263 58293 +30
Branches 7216 7210 -6
=======================================
+ Hits 50338 50364 +26
- Misses 7761 7765 +4
Partials 164 164 ☔ View full report in Codecov by Sentry. |
a4d4a02
to
455ed00
Compare
Benchmark ResultMaster commit hash:
|
Benchmark ResultMaster commit hash:
|
Description
This PR fixes two problems related to the usage of transactions:
For the first problem, the PR moves resolving data type of default null from Parser to Binder, thus, Parser doesn't rely on transactions.
For the second problem, the PR unifies how transactions should auto begin and commit/rollback in
TransactionHelper::runFuncInTransaction()
, and avoids unnecessary begin/commits of transactions.