so this tool is actually insanely nice. i really like how productive i am with sql-clojure-interop. but i was curious: what would be some use cases where one wouldnt recommend hugSQL?
We use it for all of our SQL/Clojure interop. However, it can get a little clunky with some of the more dynamic queries. Obviously there is support for dynamically constructing not just the parameters but all aspects of the query by allowing you to generate SQL string portions via clojure. However, if you have a very high degree of dynamism within your SQL Queries, honeysql is probably a more appropriate choice.
Seconding honeysql, HugSQL work very well in the past but over time I observed a query explosion and once we started reaching for conditionals in hugsql queries things really started to get out of hand. HoneySQL makes things more organized because query composition boils down to data processing, rather than string manipulation
dumb question, but could you elaborate on conditionals a bit? i would love to see an example of this. to avoid running into this problem later on.
I don't have access to the source code anymore, but I do remember the unholy mix of: • snippets: https://hugsql.org/using-hugsql/composability/snippets • and clojure expressions https://hugsql.org/using-hugsql/composability/clojure-expressions that was used to build parametrized queries where you could decide how to filter records and which columns to return, it was really hard to debug - I think at some point we wrote tests for generated sqlvecs :-/
i guess i havent thought about the possible that one's schema would be static, but the result sets one wants could change a lot.
it feels like something that would happen in an environment where data feedback is important for the system as a whole
in my case, the only place that would be is web analytics. and im still debating wether i should set up my own sql tables for this (it feels like the cheaper option)