3.6 DB nodes (preview) - customising default converters

I was wondering if there is a way to configure the default set of converters?
Our database uses SMALLINT everywhere, and it is a pain in the backside to keep getting errors every time when adding new nodes to the workflow, and to keep adding the required converter to the list every time.
Would be nice if all nodes had the required set and were ready to go.

6%20DB%20preview%20-%20default%20converters

Hi,
this is an interesting idea. So far the default converters are hard coded. Where would you put this functionality? Right now two possible solutions come to my mind:

  1. An additional tab in the DB Connector nodes (including all of the db specific connector nodes e.g. Postgres Connector etc.). Which will allow you to specify the default converter per DB connection.

  2. KNIME preferences next to the JDBC driver registration where you would specify the default converter globally for all DB connections.

Maybe we could also have both where the DB Connector tab is pre-filled with the global mapping rules.

We will also add the option to specify the type mapping by column name to allow users to specify type mapping by column name or regular expression (see attached screenshot).
This is especially useful for DB types that could be mapped to different KNIME types such as binary.

image

What do you think about the new type mapping framework in general?
Thanks for taking the time to try out the new framework and providing feedback
Tobias

1 Like

I assume by global you mean “all new connections using that driver”, which would be my preferred option, rather than all connections using any driver - not something I’d recommend, as different databases may need different setup.

It would also be nice to be able to override the pre-configured default driver’s set of converters in the Connection node, for any special cases.

The Connection node is certainly a better place for it, rather than individual query nodes. I can’t think of a scenario where different conversions will be needed on the same connection.

The Mapping by name is certainly also useful, but what if it is in conflict with the Mapping by type?

Also I’m not sure how RegEx based mapping will work - all column names that fit RegEx pattern?

Overall, the ability to control the data type conversions explicitly is great, as opposed to hoping that the node will do the right thing in the background. But it is painful to make changes to every node currently.

The other concern is to make sure that the conversion results are what is expected, especially for complicated cases like -> Number -> Boolean and so on. Some sort of preview would be great, I guess the planned data preview in relevant nodes would solve that, but it would be great to have an indication on which conversion was applied to each field (maybe in the column header tooltip?)