Python Extension Node - Table metadata interface

Dear all,

In my Python-based Nodes implemented via the Knime Python Extension Development API I’d like to make use of table metadata of the following kind:

  • per-table metadata: dict-like metadata which applies to the whole table, f.i. timestamp, created by, licensing, … –> seems to be unsupported by Knime
  • per-column metadata: dict-like metadata applying to each column. –> seems to be supported by Knime for the schema, but not for the data

In most cases, this metadata is available after loading the data, thus we can’t set it to the Schema in configure(), instead we’d like to set it in execute() after retrieving data and related metadata from our sources.

Looking at the Knime Extension API, it seems that Table doesn’t overload the abstractmethod schema meaning we cannot access table metadata coming via an input table. Is that correct?

Further inspecting other classes like TabularView, ColumnarView, _Tabular (sorry, underscores are converted to italic, even when using preformatted text) and the schema.py module it seems like metadata is only available for Schema-like definitions used in configure(), but not for data objects in execute().

Thus I’d like to ask

  • Is there any way to access and set metadata from within execute(), f.i. via exec contest such that following nodes see the metadata?
  • If yes: Can we depend upon this method or is it likely to see disruptive changes in the future?
  • If not: Do you plan to provide something like this in the future?
  • Is the metadata interface planned to be extended (non-disruptive) in the future, f.i. by having a standardized access to metadata from Table classes or by adding per-table metadata?

@carstenhaubold Sorry to ping you again, but I’d guess that you are the correct contact person wrt. this topic. :slight_smile:

Best regards and thanks in advance,

Johannes

P.S.: When working with metadata is possible, then we might of course use a dummy column for the per-table metadata as a fallback-option. But having a standardized per-table metadata interface would of course be quite nice. :slight_smile: