It would be nice to be able to create structured filters from pydeephaven; aiming for an interface that looks something like the server side deephaven.filters would likely be best. or_, and_, not_, is_null, is_not_null should all be easily doable via the respective table.proto Condition message types.
We may want to introduce a new Condition message to fully encapsulate the functionality currently present in pattern; while we have MatchesCondition and ContainsCondition, they are specializations of pattern.
For reference, here is how they map:
@Override
public WhereFilter onContains(Reference reference, String searchString, CaseSensitivity caseSensitivity,
MatchType matchType) {
final int flags = caseSensitivity == CaseSensitivity.IGNORE_CASE ? Pattern.CASE_INSENSITIVE : 0;
return WhereFilter.of(FilterPattern.of(
ColumnName.of(reference.getColumnName()),
Pattern.compile(Pattern.quote(searchString), flags),
Mode.FIND,
matchType == MatchType.INVERTED));
}
@Override
public WhereFilter onMatches(Reference reference, String regex, CaseSensitivity caseSensitivity,
MatchType matchType) {
final int flags =
(caseSensitivity == CaseSensitivity.IGNORE_CASE ? Pattern.CASE_INSENSITIVE : 0) | Pattern.DOTALL;
return WhereFilter.of(FilterPattern.of(
ColumnName.of(reference.getColumnName()),
Pattern.compile(regex, flags),
Mode.MATCHES,
matchType == MatchType.INVERTED));
}
It would be nice to be able to create structured filters from pydeephaven; aiming for an interface that looks something like the server side
deephaven.filterswould likely be best.or_,and_,not_,is_null,is_not_nullshould all be easily doable via the respective table.protoConditionmessage types.We may want to introduce a new
Conditionmessage to fully encapsulate the functionality currently present inpattern; while we haveMatchesConditionandContainsCondition, they are specializations ofpattern.For reference, here is how they map: