Better generalizability for the reorder-columns operation

[wetneb]

We offer an operation, reorder-columns, which is able to change the order of columns in an arbitrary way and remove any number of columns, in a single step.

The operation which corresponds to this screenshot is represented internally as:

  {
    "op": "core/column-reorder",
    "columnNames": [
      "Identifiant du lieu",
      "Année du tournage",
      "Type de tournage",
      "Titre",
      "director",
      "producer",
      "Réalisateur",
      "Producteur",
      "Code postal",
      "Coordonnée en X",
      "Coordonnée en Y",
      "geo_shape",
      "geo_point_2d"
    ],
    "description": "Reorder columns"
  }

In other words, the operation parameters simply remember what is the final order of the remaining columns after reorder. As explained in #4055, this operation does not generalize well to other datasets, when it is used in the "Apply" dialog of the Undo/Redo tab, because any columns that were not in the original dataset but are present in the new one will be deleted by this operation.

Proposed solution

We should find other ways to specify this operation so that the actual intent of the user is captured better. It is difficult to come up with a precise specification, but as a litmus test, I would expect the following criteria to be satisfied:

• If I use the dialog above to delete columns only, without reordering the remaining columns, I would expect that the generalization of this operation only deletes the said columns, and leaves any other column (including those not present in the original dataset) untouched. This could be achieved by calling the column-removal operation instead, as it supports removing multiple columns at once after #5563.
• If I use the dialog to reorder columns only, without deleting any column, then I expect that the generalization of this operation will not delete any column in any other context. Additional columns not present in the original dataset should be placed in a sensible location in the resulting table. It is not a problem if this exact order is complicated to define, as the exact position of columns should generally not have a significant influence on operation workflows except in certain cases (such as the use of transpose operations).

Alternatives considered

One could decide to break down the operation into multiple steps, applying the operations that remove or move a single column multiple times, to reach the desired state. Working on such a decomposition is likely useful to understand this issue better, but I would rather prefer that this dialog does not generate lengthy lists of steps in the project history.

Additional context

Follow-up to #4055 and #5563.

[thadguidry]

I tend to agree with the proposal. So are you for/against splitting the dialog into two menu items? I am against splitting the dialog as it flows well, to reorder a few columns and delete/don't care about these other columns. Behind the scenes, the current operation itself could be split into multiple operations. Agree on non-lengthy lists but they are lengthy often enough when dealing with wide datasets, so.

[wetneb]

Yes I would keep the dialog as is.