-
Notifications
You must be signed in to change notification settings - Fork 9
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
Support Spark's "struct" function #67
Comments
Support for structured data types is not strong in the engines with Substrait support. We will need to improve the backend support before we can make further progress here. In addition to supporting the type itself there are a myriad of operations (including access as if the struct was a dictionary using square brackets) that should also be implemented. |
The linked PR uses I've set the PR to draft for now and I'm trying to grok the comment about |
The struct type is defined (and documented in the compound types section). Implementing struct() on its own is fine -- it will need to be done eventually. The problem is what comes after you have the struct as we don't have anything that works on them. |
Re: The requested functionality unblocks some
|
DuckDB did add more struct support to Substrait this week but I believe we need nested expressions to handle this properly. Turns out the substrait-validator doesn't have support for nested expressions either. So support will need to be added to the validator and DuckDB. I've filed a request for DuckDB to look into nested expressions. |
Nested support has been added DuckDB's Substrait implementation today. It will be in their next release. So now just the validator and the gateway need updating. |
I see the commits. I'm taking a crack at another PR for the gateway. |
When DuckDB's release lands (in the next week or two) I'll take a crack at this. |
The problem with struct_pack is that you would need a version of the function with varying output signatures (one for every output type you could generate). Substrait introduced a feature called nested expressions that handles this. Here's what the pyspark code above will look like with one change. DuckDB doesn't have any names for the constructed structure so struct_extract (used to implement get_field) has to use number references instead of string references. That's fixable since I have the names when I'm converting get_field. The other hidden gotcha is that the output names now needs a more complicated datastructure as each of the struct's fields needs to also be there.
|
Update: I have a PR that should work except for the returned data from DuckDB does not have names on the struct fields (they are empty strings). I've filed an issue but it should be possible to work around the issue by repackaging the data before returning it. |
#91 is now ready for review. I will need to find someone who can review and merge it. However in the meantime it is available for playing with. Note that there are two current limitations:
To address these two shortfalls requires keeping track of the types (and the associated names) throughout the plan conversion process. The refactoring in this PR makes that possible. |
Usages of the SparkSQL function
def struct(cols: Column*): Column
fail with an error message -"Exception iterating responses: Function struct not found in the Spark to Substrait mapping table."
The text was updated successfully, but these errors were encountered: