You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This ticket tries to make a case for a more type safe API for transport . Our API today IMO lacks in two ways :-
The containers API - Struct, Map and Array is not parameterized. This means that for consuming elements from these containers requires a typecast. E.g taking a Int out of a map would mean taking StdData out and then typecasting it to a StdInt.
The StdUDF API is parameterized, but the parameters extend StdData. This is limiting because :-
I think we can do better, and though Presto may have some unknowns, I was able to achieve some success with a Spark prototype. Below I try to give an idea of my approach
Containers API
As described in #7, I chose java.util.{List, Map} for List and Map types. For Struct I defined a Record type, similar in line to Avro's GenericRecord. The key point here is the all these container APIs are parameterized as shown below
This ticket tries to make a case for a more type safe API for
transport
. Our API today IMO lacks in two ways :-Int
out of amap
would mean takingStdData
out and then typecasting it to aStdInt
.I think we can do better, and though Presto may have some unknowns, I was able to achieve some success with a Spark prototype. Below I try to give an idea of my approach
Containers API
As described in #7, I chose
java.util.{List, Map}
for List and Map types. For Struct I defined aRecord
type, similar in line to Avro'sGenericRecord
. The key point here is the all these container APIs are parameterized as shown belowSo to get a field out of a record, we'd do
This does not involve any typecasting and is type safe. Similar examples can be given for other container types.
UDF API
Similarly, for UDF API, we can have generic parameters which need not extend
StdData
. Below I provide the API I used in my prototype.This would help us implement #7 cleanly and in a type safe manner, and would make #6 possible
The text was updated successfully, but these errors were encountered: