A reference row filter is then done keeping rows in table 1 when the inchi is also in table 2. This works as expected and we get a smaller table.
However, when using a joiner to produce an inner joined table on these two tables an empty table is produced. The indicates the type of both columns is String.
When creating a new string cell (removing the adapter type) in a java snippet the joiner works as expected.
Should the joiner and reference row filter behave the same way when evaluating cell equality?
A further check indicates that the column comparator has the same behaviour as the reference row filter.
Better late than never…
The problem in your example is using the Column Rename node. It works fine for renaming columns but changing their type usually doesn’t do what you expect. Offering this functionality in this node was a big mistake back in the time that keeps bugging users.
What happens in your case is that even though the “renamed” column looks like a string column it isn’t. As you noticed yourself, you get this strange non-native type. This only affects the type of the column but does not change the cells in the column at all. Now, when the Joiner compares the two cells and sees a String cell and an Inchi cell. Those are are not equal because despite both essentially containing a string, the string cell says my preferred representation is “string” whereas the Inchi cell says it’s “Inchi”. And those cannot be compared with each other and therefore the cells are not equal.
Lesson: don’t use the Column Rename node for anything else than renaming the column.
