Github user hvanhovell commented on the pull request:
https://github.com/apache/spark/pull/9642#issuecomment-156693107
```UnsafeRow``` and ```SpecificRow``` have similar problems. Shouldn't we
fix those as well? For example:
import org.apache.spark.sql.types.IntegerType
import org.apache.spark.sql.catalyst.expressions.SpecificMutableRow
import org.apache.spark.sql.catalyst.expressions.UnsafeRow
val srow = new SpecificMutableRow(IntegerType :: Nil)
srow.isNullAt(0)
srow.getInt(0)
val urow = new UnsafeRow()
urow.pointTo(new Array[Byte](16), 1, 4)
urow.isNullAt(0)
urow.getInt(0)
// Result:
import org.apache.spark.sql.types.IntegerType
import org.apache.spark.sql.catalyst.expressions.SpecificMutableRow
import org.apache.spark.sql.catalyst.expressions.UnsafeRow
srow: org.apache.spark.sql.catalyst.expressions.SpecificMutableRow =
[null]
res129: Boolean = true
res130: Int = 0
urow: org.apache.spark.sql.catalyst.expressions.UnsafeRow = []
res133: Boolean = false
res134: Int = 0
I'd actualy rather not touch this at all. When you are using internal API
you should be more carefull and expect some quirkiness.
I can currently think of only one place in which this causes some problems:
UDFs with primitive parameters. The engine will pass in default values instead
of nulls. Are there any other situations in which this causes problems?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
