-
Notifications
You must be signed in to change notification settings - Fork 41
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
Tables.materializer should return a StructArray #291
Comments
The proposed implementation is probably something like fromtable(cols) = StructArray(Tables.columntable(cols)) # so we ensure that _all_ Tables compliant objects are supported
Tables.materializer(X::StructArray) = fromtable And one can use CSV.read(filepath, StructArrays.fromtable) or Arrow.Table(file) |> StructArrays.fromtable (see also brief discussion in #276 (comment)). As #289 and #290 also involve slight changes in behavior, maybe it's best to be completely safe and mark those two plus this change as 0.7 I'll be travelling for the holidays but was planning to make a PR for this shortly after that. |
Thanks @piever ! |
Added fromtable and materializer to my "table-support" PR #276. |
We currently have this behavior, which is not optimal:
When using
Tables.materializer
on aStructArray
we probably don't want to get something that generates plain vectors of named tuples. IfX isa StructArray
then we should also haveTables.materializer(X)(Tables.columns(X)) isa StructArray
(TypeTables.Table, for example, behaves like this).I propose to specialize
Tables.materializer
like this(Returning a function
_materialize_sa
instead ofStructArray
directly helps with type stability). This will result inQuestions is, should this be considered to be breaking, requiring a v0.7 release?
The text was updated successfully, but these errors were encountered: