Open devinrsmith opened 4 weeks ago
Part of the issue might be the "unclear" semantics of the advanced filter "contains". It looks like the web UI is creating an 'InvokeCondition' w/ the "match" method and regex (?s)(?i).*\\QAP\\E.*
. 1) It's not clear to me that this should be case insensitive by default, and 2) 'ContainsCondition' would be much more appropriate and performant (regardless if case-insensitive or not).
I would argue it should be case-sensitive by default (for performance reasons), with a checkbox to turn it into a case-insensitive match.
I do want to also argue the case for #3609 (revamping the Filter grpc API), also related to #3784.
I believe this is really a JS API issue, in two ways, not something we need to address in the server or js api:
dh.FilterValue.invoke()
call shouldn't be used here anyway, it should be dh.FilterValue.matches(pattern:FilterValue)
(or matchesIgnoreCase
) instead, which will be evaluated on the server as a FilterPattern
, with a pre-computed pattern instance.dh.FilterValue.contains()
(or containsIgnoreCase
) - today this will also evaluate to a FilterPattern
on the server, but there's no specific reason that this must be true.Thoughts @mofojed?
Note, web-client-ui ticket created / linked above. (I didn't realize at the time, but I think you can move issues from one repo to another.) Happy to close this one out.
When executing a "contains" on a String column in via the web UI, a pattern is compiled for every single comparison.
Ideally, this would instead use a
io.deephaven.api.filter.FilterPattern
/io.deephaven.engine.table.impl.select.WhereFilterPatternImpl
.Potentially related to #3784, #3425