-
Notifications
You must be signed in to change notification settings - Fork 63
Partiql eval continue #1370
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
Partiql eval continue #1370
Conversation
Conformance comparison report-Cross Engine
Number failing in both: 254 Number passing in eval engine but fail in legacy engine: 181 Number failing in eval engine but pass in legacy engine: 975 Conformance comparison report-Cross Commit-EVAL
Number failing in both: 1227 Number passing in Base (d749103) but now fail: 2 Number failing in Base (d749103) but now pass: 106 Click here to see
Conformance comparison report-Cross Commit-LEGACY
Number failing in both: 435 Number passing in Base (d749103) but now fail: 0 Number failing in Base (d749103) but now pass: 1 Click here to see
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## partiql-eval #1370 +/- ##
===============================================
Coverage ? 50.32%
Complexity ? 1045
===============================================
Files ? 165
Lines ? 13129
Branches ? 2452
===============================================
Hits ? 6607
Misses ? 5862
Partials ? 660
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
val c = coercions[i] | ||
when { | ||
c == null -> return false | ||
c.input != args[i].type -> return false | ||
c.target != types[i] -> return false | ||
} |
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.
Could you please add a one-line comment to clarify the conditional?
val c = coercions[i] | ||
when { | ||
c == null -> return false | ||
c.input != args[i].type -> return false | ||
c.target != types[i] -> return false | ||
} |
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 feel like the logic can be simplified and should be a bit different:
internal fun matches(args: Array<PartiQLValue>): Boolean {
for (i in args.indices) {
val target = coercions[i]?.input ?: types[i]
if (args[i].type != target && target != PartiQLValueType.ANY) { return false }
}
return true
}
Since we've already pre-computed the coercions, we can assume that c.target != types[i]
should never return true. And, while this isn't part of your PR, there is a bug in line 63-64.
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.
By bug you mean we can not return true if only one signature parameter if ANY right?
partiql-types/src/main/kotlin/org/partiql/value/util/NumberExtensions.kt
Outdated
Show resolved
Hide resolved
@@ -84,7 +84,7 @@ class EvalExecutor( | |||
if (v1.isNull && v2.isNull) { | |||
return true | |||
} | |||
if (v1 == v2) { | |||
if (comparator.compare(v1, v2) == 0) { |
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.
NULL/MISSING according to your other comment would cause problems here, right?
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.
We should not use the comparator here, we should have the equals or hash code method implemented in the value class.
But the comparator is at the moment the only comparator, specifically when it comes to bag comparison.
I think we can leave this line here but add a TODO.
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.
Is there a specific scenario where this was failing? I can see that all of the value impls are data classes with the exception of collections and structs.
val flattenedArgs = args.map { | ||
if (it is AnyOfType) { | ||
it.flatten().allTypes.filter { it !is NullType } | ||
} else { | ||
it.flatten().allTypes | ||
} | ||
} |
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 when the StaticType is AnyType? Would the following suffice?
val flattenedArgs = args.map { | |
if (it is AnyOfType) { | |
it.flatten().allTypes.filter { it !is NullType } | |
} else { | |
it.flatten().allTypes | |
} | |
} | |
val flattenedArgs = args.map { it.flatten().allTypes }.filter { it !is NullType } |
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.
Intuitively, if the input args is just a StaticType.NULL
, then this will return an empty list, which might cause some trouble.
I will look into this.
…ensions.kt Co-authored-by: John Ed Quinn <[email protected]>
dbf8b62
to
7f0c978
Compare
// Input type is null | ||
// input type is the same as function parameter | ||
null -> { | ||
if (!(inputType == parameterType || inputType == PartiQLValueType.NULL || parameterType == PartiQLValueType.ANY)) { |
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 discussed this earlier today, but IMO the input, if null, should be coerced to a typed null ahead of time. We don't need the check for inputType == PartiQLValueType.NULL
.
We could address the NULL aspect later, though.
if (inputType != c.input) return false | ||
// checking the result is expected by the function signature | ||
// this should branch should never be reached, but leave it here for clarity | ||
if (c.target != parameterType) return false |
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 honestly think we can just delete this code path -- clarity or not. A comment should suffice.
And, if, for some reason this branch is hit and the types don't line up, we need to know about it. AKA we should let evaluation proceed so that we can actually retrieve the exception when the function is invoked with wrong types. We wouldn't want to silence our bugs.
Relevant Issues
Description
Other Information
Updated Unreleased Section in CHANGELOG: [YES/NO]
Any backward-incompatible changes? [YES/NO]
errors for users that are using our public APIs or the entities that have
public
visibility in our code-base. >Any new external dependencies? [YES/NO]
Do your changes comply with the Contributing Guidelines
and Code Style Guidelines? [YES/NO]
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.