Comment by hombre

I thought this was just going to be the same ol "where id = {id}" interpolation but dang, those are some crazy examples.

I can imagine the behavior takes some trial and error to figure out, but it looks like you can write a search() query that contains fully-loaded sql statement as if all facets were provided, yet you can make each facet optional and those expressions will get removed from the statement.

That would be much nicer than the traditional route of building up a where clause with a bunch of if-statements where it's very hard to understand what the final where clause might look like without print(statement).

I'd rather write the whole SQL statement upfront which this seems to let you do.

> the traditional route of building up a where clause with a bunch of if-statements where it's very hard to understand what the final where clause might look like without print(statement).

Seems similar on this front? You also need to print the final SQL to understand what the query looks like, what conditions have been dropped etc.

What you write still isn’t the sql that’s actually executed, it’s some sort of template.

In general I find that the right approach is to avoid the conditional clauses altogether: instead of repository methods with many options, make several dedicated repository methods. You repeat a good amount of sql, but it’s so much simpler, easier to understand what’s happening, closer to the use-case, easier to optimise…

Comment by hombre_fatal