-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
drop columns
gives wrong results or errors for tables with "holes"
#10902
Labels
inconsistent-behavior
Behavior between different commands or types inconsistent/unexpected
tabled
Issues about our new table renderer (tabled)
Comments
yeah that sounds like a bug, good catch 😮 |
amtoine
added
tabled
Issues about our new table renderer (tabled)
inconsistent-behavior
Behavior between different commands or types inconsistent/unexpected
and removed
needs-triage
An issue that hasn't had any proper look
labels
Nov 1, 2023
sholderbach
pushed a commit
that referenced
this issue
Nov 9, 2023
# Description This PR refactors `drop columns` and fixes issues #10902 and #6846. Tables with "holes" are now handled consistently, although still somewhat awkwardly. That is, the columns in the first row are used to determine which columns to drop, meaning that the columns displayed all the way to the right by `table` may not be the columns actually being dropped. For example, `[{a: 1}, {b: 2}] | drop column` will drop column `a` instead of `b`. Before, this would give a list of empty records. # User-Facing Changes `drop columns` can now take records as input.
hardfau1t
pushed a commit
to hardfau1t/nushell
that referenced
this issue
Dec 14, 2023
# Description This PR refactors `drop columns` and fixes issues nushell#10902 and nushell#6846. Tables with "holes" are now handled consistently, although still somewhat awkwardly. That is, the columns in the first row are used to determine which columns to drop, meaning that the columns displayed all the way to the right by `table` may not be the columns actually being dropped. For example, `[{a: 1}, {b: 2}] | drop column` will drop column `a` instead of `b`. Before, this would give a list of empty records. # User-Facing Changes `drop columns` can now take records as input.
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this issue
Feb 20, 2024
# Description This PR refactors `drop columns` and fixes issues nushell#10902 and nushell#6846. Tables with "holes" are now handled consistently, although still somewhat awkwardly. That is, the columns in the first row are used to determine which columns to drop, meaning that the columns displayed all the way to the right by `table` may not be the columns actually being dropped. For example, `[{a: 1}, {b: 2}] | drop column` will drop column `a` instead of `b`. Before, this would give a list of empty records. # User-Facing Changes `drop columns` can now take records as input.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
inconsistent-behavior
Behavior between different commands or types inconsistent/unexpected
tabled
Issues about our new table renderer (tabled)
Describe the bug
drop columns
will only keep columns present in the first row. So, if the rows after the first have columns not present in the first, these columns will also be dropped. Similarly, if the rows after the first do not have all the retained columns of the first row, the command errors withnu::shell::column_not_found
.How to reproduce
[{a: 1}, {b: 2, c: 3}] | drop column
gives:[{a: 1, b: 2}, {c: 3}] | drop column
gives:Expected behavior
[{a: 1}, {b: 2, c: 3}] | drop column
should give:or
[{a: 1, b: 2}, {c: 3}] | drop column
should give:or
Screenshots
No response
Configuration
Additional context
No response
The text was updated successfully, but these errors were encountered: