hugsql

I think HugSQL[1] (Clojure library) has really opened my eyes to what DB interaction should be like. It’s not exactly an ORM, but it protects you from SQL injection and makes it convenient to leverage the capabilities of your SQL database. Also, his name is Usain Bolt[2]. [1] https://github.com/layerware/hugsql [2] https://en.m.wikipedia.org/wiki/Usain_Bolt

I’ve used Clojure’s hugsql[0] and C#’s dapper and petapoco[1]. I rather liked the result. You don’t generally build dynamic strings (though sometimes you do). You generally write parameterized SQL in a fairly straightforward way with these. Honestly, SQL + Clojure is a great combo. Datalog + Clojure is even nicer. [0] https://github.com/layerware/hugsql [1] https://github.com/CollaboratingPlatypus/PetaPoco

> The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. Yeah, this is the part that's the problem, not the migrations themselves. Keeping this boilerplate in sync with the db is the bane of my existence in my framework and is a completely unnecessary task. Using the ORM itself is even worse, but I digress. In apps I started from scratch, I dropped all that garbage in favor of repositories that send straight SQL to the db and all these issues dissapeared, including the slow 10x query overhead. > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Maybe it's true for Rails, but there are plenty of frameworks that wo

Here's a clojure library designed around it. (https://github.com/layerware/hugsql) Not a fan of this strategy in particular, but I can see arguments for it.

Have used Hugsql[1] and love it. I find I always hit the limitations of other DSL like solutions eventually and it costs a lot of time. I found I didn't often need the ability to compose the SQL as data that Honey SQL offers and Hugsql has the concept of 'snippets' to handle those few situations. I have found the ability to just write SQL as a template is simpler, no translation and unsupported operation problems. It is however a two edged sword, with out that convenience layer you get no abstraction over the SQL that you write so it may not work across different SQL implementations but personally that is not really something I value very much and value the ability to use all the features of the particular database I am targeting. [1] https://github.com/layerware/hugsql