-
Notifications
You must be signed in to change notification settings - Fork 28.1k
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
[SPARK-8784] [SQL] Add Python API for hex and unhex #7181
Conversation
cc @rxin @zhichao-li |
* Resulting characters are returned as a byte array. | ||
*/ | ||
case class Unhex(child: Expression) | ||
extends UnaryExpression with AutoCastInputTypes with Serializable { |
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.
can you use ExpectsInputTypes here? since I will remove AutoCastInputTypes.
Merged build triggered. |
Merged build started. |
checkEvaluation(UnHex(Literal("737472696E67")), "string".getBytes) | ||
checkEvaluation(UnHex(Literal("")), new Array[Byte](0)) | ||
checkEvaluation(UnHex(Literal("0")), Array[Byte](0)) | ||
checkEvaluation(Unhex(Literal("737472696E67")), "string".getBytes) |
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.
add a test for null literal of string type
Test build #36358 has started for PR 7181 at commit |
} | ||
|
||
// lookup table to translate '0' -> 0 ... 'F'/'f' -> 15 | ||
private[this] val unhexDigits = { |
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.
can we move the two tables into some static field in an object?
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 can, but putting them here is more clear. Only one object per Expression, I think it's fine.
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.
why would it be more clear? are you thinking about the distance between its definition and where it is used?
this is one case where java beats scala with static fields. Ideally all the string functions should just be member functions in UTF8String.
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.
Less code is better than more code. From performance's point of view, there is never an end to stop optimize it. I think we could go with something that's good enough (won't be the bottle neck).
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.
how is this less code? It is just a bad idea to create unnecessary state. Just move both tables into two fields in Hex object.
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.
BTW I absolutely disagree that "less code is better than more code" as an ethos. While it can be true in many cases, there are plenty of counter examples:
- putting everything into a single file without any namespacing reduces the import statements, but that creates bad logical structures
- not writing any test cases reduces the amount of code also, but that's obviously bad
- using arcane scala features can substantially reduce code size in certain cases, at the expense of readability
In this case, I don't see how this creates less code (it takes 2 lines of code to define a scala object -- you can even put it in an existing java class like in UTF8String as a static field).
Merged build triggered. |
Merged build started. |
Test build #36362 has started for PR 7181 at commit |
Test build #36358 has finished for PR 7181 at commit
|
Merged build finished. Test FAILed. |
The test failed because of |
} | ||
// two characters form the hex value. | ||
while (i < bytes.length) { | ||
if (bytes(i) < 0 || bytes(i + 1) < 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.
There would be exception on my previous logic when facing non-ascii character. Thanks for fixing this.
Test build #36362 has finished for PR 7181 at commit
|
Merged build finished. Test FAILed. |
Build triggered. |
Build started. |
Test build #36416 has started for PR 7181 at commit |
Test build #36416 has finished for PR 7181 at commit
|
Build finished. Test FAILed. |
Build triggered. |
Build started. |
Test build #36423 has started for PR 7181 at commit |
Conflicts: sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/math.scala sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/MathFunctionsSuite.scala
Merged build triggered. |
Merged build started. |
Test build #36429 has started for PR 7181 at commit |
Test build #36423 has finished for PR 7181 at commit
|
Build finished. Test PASSed. |
Test build #36429 has finished for PR 7181 at commit
|
Merged build finished. Test PASSed. |
Thanks - merging this in master. |
I reverted the patch since it broke the build. Can you submit a new PR? |
Was the build break caused by racing merges? |
Not 100% sure. |
Also improve the performance of hex/unhex