MaxGekk commented on code in PR #51337:
URL: https://github.com/apache/spark/pull/51337#discussion_r2179430018
##########
connector/avro/src/test/scala/org/apache/spark/sql/avro/AvroSuite.scala:
##########
@@ -1762,7 +1762,9 @@ abstract class AvroSuite
}
test("error handling for unsupported Interval data types") {
- withSQLConf(SQLConf.LEGACY_INTERVAL_ENABLED.key -> "true") {
+ withSQLConf(
+ SQLConf.STABLE_DERIVED_COLUMN_ALIAS_ENABLED.key -> "false",
Review Comment:
> I think it's better to randomly switch this conf here and there.
It is good idea, but before implementing this we should make sure that
existing tests are reliable to such behaviour otherwise we will destabilize the
existing CI.
> We just need to publish a good habit for writing tests
Habits is nice, and I believe if a test writer assumes some naming
convention, this assumption should be explicit via a config set otherwise
he/she should assign an alias. How about to put this statement to the coding
style?
> alias the expressions when necessary to have stable alias.
I will do when it is obvious, but some tests are depend
`SQLConf.STABLE_DERIVED_COLUMN_ALIAS_ENABLED` for unknown reasons at least for
me (I cannot say why without investigation). For instance, the simple case
where names should be the same in plan and in the query independently from the
config:
```scala
test("SPARK-42552: select and union without parentheses") {
val plan = Distinct(OneRowRelation().select(Literal(1))
.union(OneRowRelation().select(Literal(1))))
assertEqual("select 1 union select 1", plan)
}
```
fails with:
```
== FAIL: Plans do not match ===
'Distinct 'Distinct
+- 'Union false, false +- 'Union false, false
:- 'Project [unresolvedalias(1)] :- 'Project [unresolvedalias(1)]
: +- OneRowRelation : +- OneRowRelation
+- 'Project [unresolvedalias(1)] +- 'Project [unresolvedalias(1)]
+- OneRowRelation +- OneRowRelation
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
