Column Expression: Row Index starts with 1 but not 0

[mwiegand]

Hi,

I happen to notice a potentially problematic inconsistency in the Column Expression node. When accessing the Row Index using rowIndex()

This has been flagged already back in April 2020 and the comment from @ScottF indicates it is present since earlier as there is a ticket AP-11609

Column Expressions rowIndex function Evaluated and executed values differ

Hi. When the Column Expressions node is used to add a column of row indexes using the rowIndex function, the “Evaluate on first row” button in the dialog returns zero. However when executed, the value in the first row of the output table is 1, so the two values disagree. (By the way I would have expected the row index in the output table to be zero-based). [image] [image] Thanks Don

Why hasn’t this been addressed? I believe the fix should be rather straight forward but please prove me wrong about this. Back when I managed a global ecommerce infrastructure this kind of bug would have fallen into the “gravel” category …

More inconvenient than an issue but a ton of gravel accumulating over time will become a serious problem, so better get it fixed now.

The test workflow as follows.

79122 - Column Expression Row Index starts with 1 but not 0 – mwiegand

Best
Mike

[nan]

Hey @mwiegand ,

indeed this has been noticed quite a while ago. However, since then there were only few requests to fix this. From our side a reason not to change this is backward compatibility. As presented at Spring Summit, we are currently working on a new Expressions node. There we take the chance to harmonize the naming and behavior of functions.

Best regards,
nan

[mwiegand]

Hi @nan,

I can related to that and was always wondering how Knime envisions software upgrades and backwards compatibility. So the general plan, please correct me if my assumption is incorrect, is to:

1. Introduce new nodes which, if fixed otherwise, would break backwards compatibility
2. Mark a certain node as “deprecated” which marks the point in time it does not receive new features
3. Eventually phase out support of deprecated nodes i.e. upon major version jumps like from 5.x to 6.0 somewhere in the future

Just one remark about the current situation. It is currently not really transparent how many bugs were reported and how many of those got or will ever get fixed. As described earlier, each bug counts towards a development dept.

At a certain point in time the amount of minuscule, gravel-like bugs will certainly be overwhelming degrading reliability to such an extend that it starting to get poisonous. Similar to the phrase “the dose makes the poison”.

Adding to this, if the community keeps reporting bugs but these have little chance to get addressed because an arbitrary number, no clarification was ever provided where the threshold is, was not reached, the level of community support will degrade as well which will hurt Knimes bottom line.

Is it planned to provide more transparency about the:

1. Update process?
2. Bugs / Features reported vs. resolved?
3. Threshold upon which a bug / feature gets addressed?

Thanks
Mike