Clojurians Log v2

I wonder if HoneySQL users wouldn’t be better off if it didn’t limit its functionality to ANSI SQL. Is anybody these days only using ANSI SQL? Rather than importing extra libraries, wouldn’t it be better to take a “batteries included” approach and bring everything in, then decide which dialect to use based on some configuration?

(I’m saying this out of pure curiosity and discussion, not suggesting that anyone should do the work)

Personally, I'm quite happy to by default enforce (in a manner of speaking) ansi sql. Keeps things regular. I like that with HoneySQL, if I do have to do something postgresql specific, I can write raw sql if I need to. but I haven't 🙂

Problem, I see, with batteries included is the sheer variation in all the db dialects and the maintainability of honeysql with that going forward.

I went to HugSQL just to be able to easily copy paste snippets and develop SQL at an SQL repl. Converting all that back to HoneySQL would be a hassle. OTOH, for some things like dynamic columns for an upsert statement etc, I use honeysql.

Yeah, maintainability is a question. But I’d say the same with having two separate libraries, maintained by two separate entities.

window functions ftw! 🙂

idk. so far I wrote extensions for honeysql once or twice while working with mysql and I'm fine with that. I also understand not wanting to maintain this type of things as it's the same reason I don't want to opensource a mysql-honeysql library with the stuff I wrote: it might be just too specific to what I was using

imo it's already hard enough writing a DSL for a DSL that has a specification. now imagine doing that for all the types of mysql engines out there, all postgresql versions, etc...

One of the big problems with multi-dialect support is that the vendors have incompatible SQL. We've already seen this with SET. There's no single precedence for SET that works for all databases. That's why there's set0 and set1 (in addition to the original sset).

There's already a HoneySQL-PostgreSQL library to extend the generic DSL. That's how dialects should work.

I think if you limit yourself to ANSI SQL, the quality of your SQL can take a nosedive, because stuff like JSON functions are not standard (which are essential for non-trivial UI queries IMO). I think the best solution for ORMs/QueryBuilders is to make a SQL -> DSL converter. I did a similar thing for SQL in .NET, though this was targeting an AST, not a query DSL. so the output is really verbose:

@isak No one is suggesting limiting anyone to ANSI SQL. The issue is that HoneySQL has to serve all users, regardless of database choice, and so it opts to support ANSI SQL (and a few non-conflicting extensions) and encourages other libraries to extend HoneySQL with database-specific syntax -- PostgreSQL seems to be the most common set of extensions via https://github.com/nilenso/honeysql-postgres

@seancorfield Ok, maybe I misinterpreted, I've just seen many people elsewhere who actually do try to limit themselves to ANSI

I agree that would be a mistake 🙂

We use MySQL (Percona 5.7) heavily at work and we certainly take advantage of MySQL-specific syntax in a lot of places. I test clojure.java.jdbc and next.jdbc against PostgreSQL but I've never used it for anything -- and I will say the vast majority of the support work I have to do on both those libs and HoneySQL is "caused" by PostgreSQL (or should I say by PostgreSQL users 🙂 ).

PostgreSQL FTW 😛

I used mariadb too a lot in the past, one of my past places of work were massive mariadb users

tis a nice db 🙂