feat: optimise where clause filtering #2076
Conversation
|
Exciting! |
robacourt
force-pushed
the
rob/optimise-where-clause-filtering
branch
from
5f3005a to
efe3613
Compare
| def affected_shapes(%Filter{} = filter, %Relation{} = relation) do | ||
| def affected_shapes(%Filter{} = filter, change) do | ||
| shapes_affected_by_change(filter, change) | ||
| rescue |
There was a problem hiding this comment.
Why is this needed? What kinds of errors do we expect to see here?
There was a problem hiding this comment.
Super safety 😄 My reasoning is that if filtering crashes, all the shapes crash, so we need to be more careful than if this was shape specific code. There's a much more targeted rescue in Table that deals with record parsing errors which is much more likely to be hit. This one is more of a catch-all just to be extra safe.
Types of error it could catch:
Shape.is_affected_by_relation_change?exceptions- change types the filter is not expecting are passed to
affected_shapes/2
These hopefully will never happen, but if they do, we'd rather the filter didn't crash.
| assert Filter.affected_shapes(filter, change("t1", %{"id" => "7"})) == MapSet.new([7]) | ||
| end) | ||
|
|
||
| assert reductions < 500 |
There was a problem hiding this comment.
Would be nice to see this specific number explain. What is the significance of it in this test? What should we do if this assertion fails?
There was a problem hiding this comment.
Good point. Let me write a comment
icehaunter
changed the title
✅ Deploy Preview for electric-next ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Fixes #2040 and is estimated to improve Trigger.dev's replication stream processing by 400x