ListEvaluationHistory query is generated dynamically.

[blkt]

Summary

This is an alternative implementation of the ListEvaluationHistory endpoint using goqu sql builder library. Generated queries are equivalent to the one implemented using sqlc.

Some of the code from internal/db/eval_history.go is taken from sqlc-generated internal/db/eval_history.sql.go in order to minimize code changes for this POC. Additionally, the generated query can be further optimized with this approach using data from filters, e.g. by reducing the number of joins when filtering by entity type.

The big downside is that the amount of glue code to write roughly doubles because of the need for custom structs and db access layer.

Change Type

Mark the type of change your PR introduces:

• Bug fix (resolves an issue without affecting existing features)
• Feature (adds new functionality without breaking changes)
• Breaking change (may impact existing functionalities or require documentation updates)
• Documentation (updates or additions to documentation)
• Refactoring or test improvements (no bug fixes or new functionality)

Testing

Currently untested.

Review Checklist:

• Reviewed my own code for quality and clarity.
• Added comments to complex or tricky code sections.
• Updated any affected documentation.
• Included tests that validate the fix or feature.
• Checked that related changes are merged.

[blkt]

This is the bulk of the change.

[eleftherias]

Thanks for writing this out @blkt! I find this code is easier to reason about because it's if statements in Go code, rather than being SQL. What's your takeaway from this? Do you have a preference between the goqu generated queries and the previous sqlc implementation?

[blkt]

Hey @eleftherias, thanks for reviewing this! 🙇

I prefer by far the sql-builder approach for several reasons, I don't think there's much to discuss from the technical perspective: generating code is almost always a better approach. Additionally, goqu has extensive support for Postgres, like WITH statements, ON CONFLICT clauses, and so on.

On the other hand, making this PR ready for merging requires more work to expose routines not generated by sqlc from the db.Querier interface.
Most importantly, once we start generating queries dynamically we loose the possibility of checking the correctness of those statement by inspection (i.e. review), and it becomes pretty much mandatory to write integration tests checking that the generated statements behave correctly. This entails test containers and potentially CI work.

[blkt]

The team agreed on closing this in favor of #3784