- Use Cases
Release Date: December 17, 2008
The most dramatic changes (i.e. under the hood) have been made to KNIME's core classes and the workflow engine in order to address future requirements such as workflow loops, flow variables and specialized port types. The changes that are most apparent to the end user are briefly listed in the following:
NodeModel#NodeModel(int, int, int, int)
DataCellimplementations need revision of
DataCellSerializerinterface (simple change of method signature)
DataCellanymore, i.e. the method
RowKey#getId()is not supported anymore
HiliteListenerneed to be fixed in order to comply with the new
RowKeyconcept. The methods in the class
HiliteHandlerwere modified accordingly.
NodeVieware now parameterized using the
NodeModelto avoid type casting and ease node development (existing node implementations will still function, though the compiler will print a warning).
We have, as a result of our discussions at the last workshop, re-implemented bitvectors. (Thus the old stuff is deprecated. Not removed though, to be able to load old workflows.)
DenseBitVector and SparseBitvector, DenseBitVectorCellFactory and SparseBitVectorCellFactory to create the corresponding DataCells that hold bitvectors.
We have implemented what we thought people may need. And we were hoping to get feedback and add more functions as people request them. With the current implementation you must decide upfront what kind of vector you want (sparse or dense). Also, you should always be aware of what kind of vector you have at hand before you do any operations on them (like AND or OR). This might not be the case (or might not be easy), thus we thought of adding a utility class that provides these operations and determines the result type automatically (this class is not in the current alpha release though).
If you are using our old BitVector stuff, there is (hopefully) not much pain involved in migrating to the new implementation. You just don't operate on Java BitSets anymore but on DenseBitVectors (which have a similar interface). And you use the factory to create the BitVectorCell after defining the bitvector.
In 2.0 our nodes that create BitVectors (from Hex/Binary/Index strings) create the new dense bitvector cells. If you have nodes that expect columns of type BitVectorValue they will not accept bitvectors from our (new 2.0) nodes until you have migrated them to our new BitVectorValue interface.
The way/sequence methods of a node view implementation are called has changed. Previously the construction, registration (for change notifications), and updates where not consistent. The new sequence is as follows:
The re-org should not require any code changes. It may solve some problems (as, for example, update is not called until NodeView construction is finished).
The preferences are divided into two parts. General runtime properties also necessary for batch execution (headless preferences) and preferences only relevant if also the KNIME GUI is started (GUI preferences).
The headless preference page has the ID: org.knime.workbench.ui.preferences
The PreferenceStore is defined under the org.knime.workbench.repository plugin, i.e. KNIMECorePlugin.getDefault().getPreferenceStore() provides access to it. The constants for the entries are defined by org.knime.workbench.preferences.HeadlessPreferencesConstants.
The GUI preference page has the ID: org.knime.workbench.ui.preferences.gui
The PreferenceStore is maintained by the org.knime.workbench.ui plugin, i.e. KNIMEUIPlugin.getDefault().getPreferenceStore() provides access to it with the constants defined in org.knime.workbench.ui.preferences.PreferenceConstants.