Almost daily, knime users in our lab show up on my desk and complain that the new (=2.2) join node does not work.
The solution is always the same: When defining the join mapping, integer columns are mapped onto double colunmns. I'm aware of the log message which shows up in the console, but hardly anybody (without a bold IT-background) can make sense out of it. (Just ask a biologist/psychologist/... what a 'type' or a 'type mismatch' could mean).
Furthermore, I don't see any reason why Knime can not match integer against double attributes. The minor change which would be necessary to implement this feature is a simple casting of the integers to become doubles before doing the matching. This enhancement would greatly ease the use of Knime.
What do you think?
ps. I haven't tried it, but i think the same applies to the "reference row filter".
You seem to appreciate the new Joiner node and its ability to join on arbitrary data columns. Thanks for that. I agree that the error message regarding "type mismatch" is not easy to undertand if you take all the type handling for granted. I will open a bug report and make sure that it's more comprehensive in future versions.
However, we try to not do any type conversion in the (preprocessing) nodes. One strength of KNIME is that columns are strongly typed and that each type translation is represented by a user step (e.g. the "Double to Int" node). If we started to soften this, e.g. by casting int to double, you could argue that you can also compare Strings and Smiles (a character sequence representing chemical structures) or even more complex objects which are just differently represented. This would be difficult and probably also often wrong (plus it's often not possible as types can be dynamically registered) so we'd like to leave this to the user.