Previous versions of these nodes used to allow for string filtering using RegEx on SMILES columns and now this is not possible. Please can this functionality be restored.
Thanks.
Simon.
Hey there,
cannot comment on KNIME’s plans to re-introduce this to the node versions in modern UI - that said given backwards compatibility you can still use the “old” nodes.
In modern UI simply type the node name into the search field followed by “//deprecated” - e.g.:
row filter //deprecated
And the “old versions” should show up with the (deprecated) tag at the end:

Hello @richards99,
May I ask what version of KNIME AP you are running? The functionality you are asking for should be a part of the Row Filter since KNIME AP versions 5.3.2 and 5.4.0.
- Marc
Hi, I’m on the latest 5.4 release and using this on a Mac.
The options are there in the drop down of the node for RegEx etc, but when I try to run the node it fails.
So when I choose RegEx and put a value in, I can click OK on the node, and then when I run it I get this error;
ERROR Row Filter 3:3426 Execute failed: (“ClassCastException”): null
This is where a Molecule column started off as String Format (of SMILES) from a CSV import, and was recast to SMILES using the Molecule Type Cast node. Row Filter node then applied directly after this.
Simon.
Hello @richards99 ,
I’m using version 5.4.3 on Windows. In the simple case bellow, thte regex seems to work with SMILES. What happens if you apply the row filter to the string format before casting? After that, I wonder if casting the filtered string to SMILES format would work well.
[Apply row filter to SMILES format after casting]
[Apply row filter String format before casting]
The filtering works fine when the filtering is applied before casting. It is just after casting where the problem is. I’m wondering if this is an Apple Mac issue.
@richards99 is there more in the knime.log than?
ERROR Row Filter 3:3426 Execute failed: (“ClassCastException”): null
It should not fail with this exception, so I consider it a bug.
@richards99 thanks so much for reporting! We actually found a bug (and fix) in the chemistry types (an assumption about the KNIME type system, that the Columnar backend needs but the Row backend does not, and which the chemistry types violate).
I can make it succeed on macOS if I use the Row backend and fail for the Columnar backend.
Great that makes sense as I do have the columnar backend on as default. I will change it to row for now. Thanks for identifying the cause of the bug.
Simon.
The internal ID is AP-24512, I’ll get it backported to 5.4 as well. There should be a notification here when a fix is released.
Internal ticket ID: AP-24512
Summary: Chemistry type value factories do not adhere to KNIME type system contract
Fix version(s): 5.4.5, 5.5.0
Hi @hotzm ,
Can I ask what the fix looks like in source code please? We have a number of internal custom types, and I would like to ensure we don’t have the same bug happening!
Thanks
Steve
Are you extending org.knime.core.data.v2.value.AbstractAdapterCellValueFactory. or implementing org.knime.core.data.v2.value.ValueFactory? If not, I don’t think you have a problem.
One note, we needed to change the API to support the bugfix: AP-24512: Provide primary access to AdapterCellValueFactory subclasses · knime/knime-core@427f7eb · GitHub and have not backported it further than 5.4.
Unfortunately, it seems the Chemistry extension is not open source (yet? I am now trying to figure out if we can open source it).
For the time being, my attempt to describe it must be enough.
The contract is: your value factory subclass must make sure that it provides ReadValue implementations that implement the same DataValue interfaces as the data cell implementation – then the unchecked casts that the columnar backend code makes, is safe.
For example, for FooCell implements FooValue, StringValue the value factory must look something like this:
class FooCellValueFactory implements ValueFactory<[...]> {
@Override
public ReadValue createReadValue(final [...] access) {
return new FooReadValue(access);
}
// ReadValue + all the same as FooCell!
private final class FooReadValue implements ReadValue, StringValue, FooValue {
[...]
}
}
Our specific bug was with how we extended the AdapterCellValueFactory which violated the contract, which made the cast fail.
Since the new Row Filter is now using the data.v2 interface directly and not going via our DataRow adapter, this bug became visible.
Don’t hesitate to ask questions :).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.


