Skip to content

Conversation

@ueshin
Copy link
Member

@ueshin ueshin commented Aug 11, 2018

What changes were proposed in this pull request?

This is a follow-up pr of #21954 to address comments.

  • Rename ambiguous name inputs to arguments.
  • Add argument type check and remove hacky workaround.
  • Address other small comments.

How was this patch tested?

Existing tests and some additional tests.

@ueshin
Copy link
Member Author

ueshin commented Aug 11, 2018

cc @cloud-fan @hvanhovell

@SparkQA
Copy link

SparkQA commented Aug 11, 2018

Test build #94599 has finished for PR 22075 at commit 3ccd995.

  • This patch fails due to an unknown error code, -9.
  • This patch merges cleanly.
  • This patch adds no public classes.

@ueshin
Copy link
Member Author

ueshin commented Aug 11, 2018

Jenkins, retest this please.

@SparkQA
Copy link

SparkQA commented Aug 11, 2018

Test build #94604 has finished for PR 22075 at commit 3ccd995.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

override def arguments: Seq[Expression] = argument :: Nil

override def inputs: Seq[Expression] = input :: Nil
def argumentType: AbstractDataType
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shall we define a def argumentTypes: Seq[AbstractDataType] in HigherOrderFunction and implement checkArgumentDataTypes there?


override def functions: Seq[Expression] = function :: Nil

def expectingFunctionType: AbstractDataType = AnyDataType
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto, why don't we define it in the HigherOrderFunction?

@SparkQA
Copy link

SparkQA commented Aug 12, 2018

Test build #94651 has finished for PR 22075 at commit 388c2d3.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
  • trait HigherOrderFunction extends Expression with ExpectsInputTypes
  • trait SimpleHigherOrderFunction extends HigherOrderFunction

@ueshin
Copy link
Member Author

ueshin commented Aug 13, 2018

Jenkins, retest this please.

assert(ex2.getMessage.contains("data type mismatch: argument 1 requires array type"))

val ex3 = intercept[AnalysisException] {
df.selectExpr("transform(a, x -> x)")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the previous behavior?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous behavior was the same. I just added to check the behavior is as expected.

// Check argument data types of higher-order functions downwards first.
// If the arguments of the higher-order functions are resolved but the type check fails,
// the argument functions will not get resolved, but we should report the argument type
// check failure instead of claiming the function arguments are unresolved.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"function arguments" -> "argument functions"?

@cloud-fan
Copy link
Contributor

LGTM

case operator: LogicalPlan =>
// Check argument data types of higher-order functions downwards first.
// If the arguments of the higher-order functions are resolved but the type check fails,
// the argument functions will not get resolved, but we should report the argument type
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, I think it's clearer to say functions, instead of argument functions. Sorry for the back and forth.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried that if we say only functions, we might be confused whether the "function" means the higher-order function or the function as an argument. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah i see, makes sense.

@SparkQA
Copy link

SparkQA commented Aug 13, 2018

Test build #94657 has finished for PR 22075 at commit 388c2d3.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
  • trait HigherOrderFunction extends Expression with ExpectsInputTypes
  • trait SimpleHigherOrderFunction extends HigherOrderFunction

@SparkQA
Copy link

SparkQA commented Aug 13, 2018

Test build #94663 has finished for PR 22075 at commit 4b48a39.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Aug 13, 2018

Test build #94668 has finished for PR 22075 at commit deee1dc.

  • This patch fails due to an unknown error code, -9.
  • This patch merges cleanly.
  • This patch adds no public classes.

@HyukjinKwon
Copy link
Member

retest this please

@SparkQA
Copy link

SparkQA commented Aug 13, 2018

Test build #94674 has finished for PR 22075 at commit deee1dc.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@ueshin
Copy link
Member Author

ueshin commented Aug 13, 2018

Jenkins, retest this please.

@SparkQA
Copy link

SparkQA commented Aug 13, 2018

Test build #94679 has finished for PR 22075 at commit deee1dc.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@cloud-fan
Copy link
Contributor

thanks, merging to master!

@asfgit asfgit closed this in b804ca5 Aug 13, 2018
s"however, '${merge.sql}' is of ${merge.dataType.catalogString} type.")
} else {
TypeCheckResult.TypeCheckSuccess
checkArgumentDataTypes() match {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a quick question: Isn't calling of checkArgumentDataTypes extra here if checkArgumentDataTypes is called as such before checkInputDataTypes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I called it here again to check the whole data types when calling checkInputDataTypes(), just in case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants