Adds support for ROW and SCALAR subquery coercion #1356
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## partiql-plugin-impl #1356 +/- ##
======================================================
Coverage ? 49.27%
Complexity ? 1046
======================================================
Files ? 166
Lines ? 13395
Branches ? 2504
======================================================
Hits ? 6600
Misses ? 6138
Partials ? 657
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Conformance comparison report-Cross Engine
Number failing in both: 431 Number passing in legacy engine but fail in eval engine: 3843 Number failing in legacy engine but pass in eval engine: 3 Click here to see
Conformance comparison report-Cross Commit-LEGACY
Number failing in both: 434 Number passing in Base (c16584f) but now fail: 0 Number failing in Base (c16584f) but now pass: 0 Conformance comparison report-Cross Commit-EVAL
Number failing in both: 4274 Number passing in Base (c16584f) but now fail: 0 Number failing in Base (c16584f) but now pass: 0 |
cda3869 to
24ffa4d
Compare
| internal class Row( | ||
| override val subquery: Operator.Expr | ||
| ) : ExprSubquery() { | ||
| @PartiQLValueExperimental | ||
| override fun eval(record: Record): PartiQLValue { | ||
| val values = getFirstAndOnlyTupleValues(record) | ||
| return listValue(values.asSequence().toList()) | ||
| } | ||
| } | ||
|
|
||
| internal class Scalar( | ||
| override val subquery: Operator.Expr | ||
| ) : ExprSubquery() { | ||
| @PartiQLValueExperimental | ||
| override fun eval(record: Record): PartiQLValue { | ||
| val values = getFirstAndOnlyTupleValues(record) | ||
| if (values.hasNext().not()) { | ||
| throw TypeCheckException() | ||
| } | ||
| val singleValue = values.next() | ||
| if (values.hasNext()) { | ||
| throw TypeCheckException() | ||
| } | ||
| return singleValue | ||
| } | ||
| } |
There was a problem hiding this comment.
Why is the subquery an Expression and not a Relation? No need to evaluate the whole expression
| @PartiQLValueExperimental | ||
| override fun eval(record: Record): PartiQLValue { | ||
| val values = getFirstAndOnlyTupleValues(record) | ||
| return listValue(values.asSequence().toList()) |
There was a problem hiding this comment.
Why list and not struct? PartiQL's "row" is the binding-tuple —> struct in the value domain
There was a problem hiding this comment.
Interesting, the specification is inconsistent on this
First it says tuple,
Furthermore, when SELECT is used as a subquery it is coerced into a scalar or a tuple,
in the ways that SQL coerces the results of subqueries. p.24
Then it says array,
SFW subquery starting with a SELECT clause (as opposed to a subquery starting with SELECT VALUE or PIVOT) coerces into a scalar or into an array, depending on the context p33
Then it says tuple again on page 33
An PartiQL extension with respect to SQL is that, in the permissive mode, subqueries that fail to coerce to the
required type (scalar or tuple) still run, as opposed to failing
It makes sense to coerce to array (list) for predicates with array literals, but perhaps a more important question is what is PartiQL's equivalent to the SQL ROW type? Or was the term "tuple" used to mean an ordered collection and not the overloaded "tuple" value.
The specification explicitly calls struct values tuple values (and the other complex values collection ie bag, array). I'm curious now which type in the data model is equivalent to the SQL ROW value — list or struct
|
Closing in favor of #1365 |
Relevant Issues
Description
How PR accomplishes this
NormalizeSelectto occur during theRelConverter's transformation.Other Information
NormalizeSelectno longer occurs in theorg.partiql.ast.normalizeAPI.and Code Style Guidelines? YES
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.