-
Notifications
You must be signed in to change notification settings - Fork 83
Handle column renaming in makeQueryTemplate and __table #345
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
Conversation
hm looks like CI is failing because |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about making this part of the existing operations.select? E.g.,
operations.select = {
columns: [
{column: "foo", as: "foo_alias"},
{column: "bar", as: "bar_alias"}
]
};
and then we’d treat the existing operations as if column
and as
were the same? I.e., this
operations.select = {
columns: [
"foo",
"bar"
]
};
would be the same as
operations.select = {
columns: [
{column: "foo", as: "foo"},
{column: "bar", as: "bar"}
]
};
oh interesting! in my first pass i had added |
@mbostock i ran into one major issue while trying to implement your suggestion, which is that it doesn't allow us to preserve the renamed name when a user hides the column. we could potentially get around this by adding a given that, i think i'd prefer to stick with this |
@annie does that mean we’re still selecting and returning columns that are hidden when the query is run? |
no we don't actually select hidden columns, we just keep the name information for that column in |
@annie Got it. Sorry, still waking up! ☕ 👍 |
No further suggestions from me. I’ll leave the reviewing to @libbey-observable and @mkfreeman! Thanks y’all. 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all makes sense and looks good to me!
@@ -659,6 +663,27 @@ export function __table(source, operations) { | |||
Object.fromEntries(operations.select.columns.map((c) => [c, d[c]])) | |||
); | |||
} | |||
if (!primitive && operations.names) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, nice, glad it was an easy fix!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the real fix for the original issue you found is actually in this change in Next! but while i was investigating i realized we should also add a check here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aaah! thanks for explaining that.
Implement column renaming in stdlib. Specifically, we now set column name overrides based on the
names
property innode.data.operations
, which is added in this PR.For SQL data sources, we do this by modifying the
SELECT
clause. For in-memory data sources, we create a copy of the source data and modify it to use the new names.