New Version = new inconsistencies

[fe145f9fb2a1f6b]

Once again, this is kind of a rant

for a past list, see e.g. Improve Path Data Type Integration - #18 by fe145f9fb2a1f6b

to add to that, lets have a look at the joiner node behavior:

in the very past (version 3 and 4) the Joiner appended a suffix ala (#1) or higher in case a column name was taken.

Then you introduced the new joiner and decided for it to append “(right)” instead as the default value (this is e.g. the case in version 5.2).

Now with the move to the modern UI (but this is also happening in the old ui)(using version 5.4), you decided again to change this (in 5.3 or 5.4) and the default that is getting appended is “(Right)” (with a capital letter to point out the difference).

I understand the logic of using Right/right but changing the default capitalization is just plain annoying.

Hence, lets have a look at another joiner we have: DB Joiner
take a guess, it uses neither “right” nor “Right”. it uses “(#1)”.

to make the list complete, lets have a look at the new “Value Lookup” node. and voila, that one uses “(#1)” again. (and lastly the column appender, same result)

AI buzz aside, 2-3 releases focused on quality control, feature maturity and feature completeness would be welcomed change

[HaveF]

I think such comparisons are very good, it does break some workflow.

[takbb]

I got caught out by this a while back when modifying an old workflow in a newer version of KNIME, which I gave feedback on here

New joiner vs old joiner - "duplicate column" suffix case has changed

I just discovered a small “gotcha” between the new Joiner (in KNIME 5.3.3, but can’t recall the exact release it appeared) and the old Joiner (KNIME 4.7.8) In the duplicate column handling, in 4.7.8 a newly placed Joiner node has the following column suffix by default: [image] (right) In KNIME 5.3.3, the new Modern UI joiner has this column suffix: [image] (Right) I just discovered this whilst trying to port a workflow back from 5.3.3 to 4.7.8 and happened to include a column filter a lit…

Changing of the default suffix in the newer node did not seem like a good thing to do, and I agree that consistency of both behaviour and configuration across nodes is not KNIME’s strong suit. For example, on nodes that can produce a new column, sometimes we can control the column naming, sometimes we can’t, sometimes we are forced to append, sometimes we have an option to replace existing. I would much prefer that there were a consistent UI in this regard.

Obviously if we are to move towards more consistency, then this will mean some inconsistency in the short term compared with older versions, but it would be interesting to know if such changes are for “future consistency” purposes, or if it simply changed because somebody did it differently (again).

[DanielBog]

Hey @takbb,

Obviously if we are to move towards more consistency, then this will mean some inconsistency in the short term compared with older versions, but it would be interesting to know if such changes are for “future consistency” purposes, or if it simply changed because somebody did it differently (again).

This is exactly the reason we are currently doing this when we switch these nodes to modern ui. We take this chance to unify all of these inconsistencies. We know that this might be a bit inconvenient for the time being, but we believe that this will ensure a consistent experience across all of our nodes. Please let us know if there are more inconsistent places, we try our best to unify them.

Greetings and thanks,
Daniel