Duplicate node names

Node Development
1

Hi there,

I have a node, I'd like to change essentially (interface + functionality). Which would mean, that workflows which have been created with this node would not work anymore when reexecuting them.

Is there a way, that I can keep this node as it is, mark it as deprecated (I know how to do this) and to create a node with the same name (in the plugin.xml) with the new features? (Class names then have to be different of course, but I could rename the classes of the 'old' node, no?

Would this approach be possible?

Or should it be handled different?

2

Our way of handling such cases is,

  • deprecate the old node (add deprecated="true" in the node-tag of the node description)
  • optionally move it to a dedicated deprecated-plug-in or to a different source folder in the same plug-in
  • remove the old node from the plugin.xml
  • create a new node with the same name, but a different class name (a different package name is already sufficient)

The old node can still be loaded (since this is performed by looking up its classes without accessing the node repository) but cannot be used in new workflows any more.

3

Thanks a lot!

That's the answer I was looking for :-)

4

Hi,

I got another problem.

I've relocated the old node to a new package (same plugin). I have implemented the new node. The plugin.xml still refers to the old node (new package path), the new node is not yet listed in the plugin.xml. But if I open an existing workflow with KNIME which contains the old node, I get a complain:

ERROR     RangeFilterFactory     CODING PROBLEM    XML node file does not conform with DTD: The content of element type "intro" must match "(p|h|br|b|i|u|tt|a|ul|ol|h3|h4|pre|sub|sup|table)".

Also, when I open the configuration dialog it looks like the new node; though this should have not been loaded, no? Can anybody explain to me what happened?

5

You must not move the old node to a new package! It must stay unchanged. The new node must be renamed or put into a different package.

6

Hmm, I still don't get why it has to be this way (as the plugin.xml refers to the new location of the old node) but I can do it this way...

I just thought it's a bit more clean, to move the old node into an "archive"-package.

Thanks so far!

7

The node in a workflow is loaded by using its class name which is stored in the workflow file. The plugin.xml is only used to building the node repository. If you change the implementation of the "old" node factory class old workflow will show the "new" node.

You can move the old node into an "archive" location, e.g. a separate plug-in (similar to org.knime.deprecated) or into a separate source folder in the same plug-in (e.g. src-deprecated parallel to src).

8

I guess, I start to understand :-)

One more question: If the old node is moved into another source folder of the same plugin - if the workflow with the old node is loaded, how does KNIME know that it should load the old implementation instead of the new one?

9

Hmm, probably I didn't get it...

I moved the old node to a new source folder in the same plugin

src-deprecated/de/../datamanip/row/

but now I get an error for duplicate classes.. :-/

I'm confused - probably the easiest way is to rename the class...

10

Of course the new node must be named differently, either the simple class name or via a different package.

11

Okay, thanks a lot for your help :-)