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

drop columns gives wrong results or errors for tables with "holes" #10902

Open
IanManske opened this issue Oct 31, 2023 · 1 comment
Open

drop columns gives wrong results or errors for tables with "holes" #10902

IanManske opened this issue Oct 31, 2023 · 1 comment
Labels
inconsistent-behavior Behavior between different commands or types inconsistent/unexpected tabled Issues about our new table renderer (tabled)

Comments

@IanManske
Copy link
Member

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 with nu::shell::column_not_found.

How to reproduce

  1. [{a: 1}, {b: 2, c: 3}] | drop column gives:
╭───┬───────────────────╮
│ 0 │ {record 0 fields} │
│ 1 │ {record 0 fields} │
╰───┴───────────────────╯
  1. [{a: 1, b: 2}, {c: 3}] | drop column gives:
Error: nu::shell::column_not_found

  × Cannot find column
   ╭─[entry #2:1:1]
 1 │ [{a: 1, b: 2}, {c: 3}] | drop column
   · ───────────┬──────────┬
   ·            │          ╰── value originates here
   ·            ╰── cannot find column 'a'
   ╰────

Expected behavior

  1. [{a: 1}, {b: 2, c: 3}] | drop column should give:
╭───┬────┬────╮
│ # │ a  │ b  │
├───┼────┼────┤
│ 0 │  1 │ ❎ │
│ 1 │ ❎ │  2 │
╰───┴────┴────╯

or

╭───┬────┬────╮
│ # │ b  │ c  │
├───┼────┼────┤
│ 0 │ ❎ │ ❎ │
│ 1 │  2 │  3 │
╰───┴────┴────╯
  1. [{a: 1, b: 2}, {c: 3}] | drop column should give:
╭───┬────┬────╮
│ # │ a  │ b  │
├───┼────┼────┤
│ 0 │  1 │  2 │
│ 1 │ ❎ │ ❎ │
╰───┴────┴────╯

or

╭───┬────┬────╮
│ # │ a  │ c  │
├───┼────┼────┤
│ 0 │  1 │ ❎ │
│ 1 │ ❎ │  3 │
╰───┴────┴────╯

Screenshots

No response

Configuration

key value
version 0.86.0
branch makepkg
commit_hash 5d8763e
build_os linux-x86_64
build_target x86_64-unknown-linux-gnu
rust_version rustc 1.73.0 (cc66ad468 2023-10-03) (Arch Linux rust 1:1.73.0-1)
cargo_version cargo 1.73.0
build_time 2023-10-18 08:45:09 +00:00
build_rust_channel release
allocator mimalloc
features dataframe, default, extra, sqlite, trash, which, zip
installed_plugins

Additional context

No response

@IanManske IanManske added the needs-triage An issue that hasn't had any proper look label Oct 31, 2023
@amtoine
Copy link
Member

amtoine commented Nov 1, 2023

yeah that sounds like a bug, good catch 😮

@amtoine 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)
Projects
None yet
Development

No branches or pull requests

2 participants