feat: DH-19045: FilterBarriers and FilterRespectsBarriers

[nbauernfeind]

This does not yet include any unit tests but is otherwise what I believe should be the rough end-to-end impl server side for filter barriers.

not ready until / still missing:

• create tests that have barriers that cross the multi-operation shenanigans of constant-array-offset access
• DVT tests

[cpwright]

The visit pattern here where we are not descending isn't perfectly clear. It seems like we should be able to descending for these and the conjunctive/disjunctive. Either way, I think Serial is deserving of a comment explaining why it is null and not descending.

[nbauernfeind]

Are we changing DVT behavior? We've never tried to bubble up components from conj/disj. In the context of MatchFilters shouldn't the invert just get pushed into the match? The match allows for a variety of comparators. I'd have to poke around more w.r.t. ConditionFilter, but I believe current main would push a not(condition) into the post view set.

Agreed, I can add a serial comment; it is because of the goal to promise the rowset it sees pass all and only previous filters.

[cpwright]

I'm thinking of it more in terms of what the intention is. The intention is to allow MatchFilter and others to rename. I think the set of renaming filters is quite limited; but the Visitor could allow us to do better. It is a bit of scope creep, so we can defer it - but I do think we should point out what is necessary for function vs. what we don't care about because DVT is (IMO - but not others) an unnecessary complexity.

[nbauernfeind]

It was relatively easy to add; will need to add unit test coverage.

[cpwright]

Does an abstract base class between these two make sense? The only real difference seems to be the four visit methods (FilterBarrier, RespectsBarrier) * (Filter, WhereFilter); but all the structural ones could be shared.

[nbauernfeind]

I'm not totally sure. Sharing an impl feels potentially an anti-pattern. I've now changed all of these callers to invoke the static of method, which tries to make the null return value (for unsupported WhereFilters) for a null list. I also separated visit and visitWhereFilter into distinct names which makes things a little more straightforward to follow. As a result, you can't just visit the inner filter, you have to go through the static helper.

Let's revisit your comment in our 1:1 tomorrow.

[cpwright]

Add the case where we can move a little bit:

Suggested change

	final Table result = sourceWithData.where(
	Filter.and(
	preFilter.withBarrier(barrier),
	RawString.of("A < 50000").respectsBarrier(barrier),
	postFilter));
	final Table result = sourceWithData.where(
	Filter.and(
	preFilter.withBarrier(barrier),
	RawString.of("A < 50000").respectsBarrier(barrier),
	postFilter));
	final Table result2 = sourceWithData.where(
	Filter.and(
	preFilter.withBarrier(barrier),
	preFilter2,
	RawString.of("A < 50000").respectsBarrier(barrier),
	));

Ideally in this case, we can move the "A" filter before preFilter2; though practically that might not work.

[cpwright]

For Enterprise ACLs we're going to have something like:

SourceTable.where(Filter.or("Group=Asdf", "GroupType=DEF))

then the user will do:
x=new HashSet<>()
.where("Date=today()", "x.add(Group)")

We need to make sure that these filters are correctly applied.

One way to think about that is that the deferred ACL table could say:
FilterBarrier.of(Filter.or("Group=Asdf", "GroupType=DEF), "ACL")
FilterRespectsBarrier("x.add(Group)", "ABC") // based on the isSimpleFilter tagging filters that can execute user code