Skip to content
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

Audit use of _promote_op #131

Closed
shashi opened this issue Feb 13, 2018 · 8 comments
Closed

Audit use of _promote_op #131

shashi opened this issue Feb 13, 2018 · 8 comments

Comments

@shashi
Copy link
Collaborator

shashi commented Feb 13, 2018

This has served us well so far, but increasingly there is frustration when you end up with a table of a single Any column. We need to use the Base.map trick as much as possible.

@piever
Copy link
Collaborator

piever commented Feb 13, 2018

Two relevant links:

  • #101 from IndexedTables and related discussion (using list comprehension is I think a common way to get the undesired column Any)
  • For the future this discourse thread, where it seems that some care is required when using map with Missings (which we don't use in this package but we will IIUC). In particular nalimilan links to many improvements he's been doing to base Julia about this issues.

@shashi
Copy link
Collaborator Author

shashi commented Feb 15, 2018

Related to your second point is a behavior in join where we speculatively create DataValue columns when doing an outerjoin lest the right table doesn't have some matches.

1 similar comment
@shashi
Copy link
Collaborator Author

shashi commented Feb 15, 2018

Related to your second point is a behavior in join where we speculatively create DataValue columns when doing an outerjoin lest the right table doesn't have some matches.

@piever
Copy link
Collaborator

piever commented Feb 25, 2018

There's one more remark. Issue #110 is also probably caused by this. In general I think a drawback of the current design is that it's difficult to use groupby in cases where the output of f has many fields (which could be generated programmatically). One side of the issue is that it's difficult to generate a NamedTuple programmatically (this problem will go away in Julia 0.7). The other side is that the type of these NamedTuples won't change from one row to the next but I don't think it will be inferrable.

For these cases (f returns many fields, generated programmatically / a bit like what summarize does as well as the issue linked above) I'm afraid the only solution for now is to create a one line table and flatten.

@piever
Copy link
Collaborator

piever commented Mar 26, 2019

This is basically fixed in IndexedTables (after JuliaData/IndexedTables.jl#226 is merged). There are still a couple of uses in JuliaDB though:

But I don't know the distributed code well enough to know if it's feasible to remove those.

@piever
Copy link
Collaborator

piever commented Mar 29, 2019

Closing as now _promote_op is not used in either JuliaDB or IndexedTables

@piever piever closed this as completed Mar 29, 2019
@joshday
Copy link
Collaborator

joshday commented Mar 29, 2019

Very nice work @piever!

@shashi
Copy link
Collaborator Author

shashi commented Mar 30, 2019

Yeah, amazing amounts of deft work! 👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants