This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-10
Channels
- # announcements (4)
- # asami (36)
- # babashka (11)
- # beginners (31)
- # calva (71)
- # clojure (51)
- # clojure-boston (2)
- # clojure-europe (3)
- # clojure-nlp (4)
- # clojuredesign-podcast (1)
- # clojurescript (30)
- # community-development (25)
- # css (1)
- # cursive (10)
- # datomic (1)
- # events (1)
- # figwheel-main (1)
- # girouette (5)
- # graalvm (18)
- # graphql (1)
- # honeysql (37)
- # instaparse (3)
- # jobs (1)
- # malli (6)
- # polylith (2)
- # releases (3)
- # remote-jobs (5)
- # rum (1)
- # shadow-cljs (16)
- # sql (1)
- # tools-deps (37)
- # vscode (11)
Hello, I'm starting a new project in clojure and I wanted some suggestions of good libraries for sql abstraction
I liked Korma, but it looks like unmaintained for a long time
I think https://github.com/seancorfield/honeysql is a pretty good way to write sql from clojure
I'm biased but I recommend next.jdbc
+ HoneySQL if you want programmatically composable SQL statements. If you prefer to write SQL and keep it in separate files to your Clojure code, look at HugSQL (and next.jdbc
for the JDBC integration).
ORM-style stuff really isn't idiomatic in Cloure (Korma, Toucan).
An interesting alternative is Walkable, where you'll get EQL (a sort of Datalog-style query language) that maps down to SQL.
(we use next.jdbc
+ HoneySQL very heavily in production at work)
@U8C850K42 Feel free to drop into the #sql channel to discuss in more depth. There's also #honeysql #hugsql #walkable
I saw hug sql and didn't like it, it remembered old ibatis in java and I missed composition that I've found in korma, I'll try next + honey
thanks for the suggestions 🙂
i recognize everyone has their own feelings about ORMs and what-not, but I don’t mind reaching for one for really well-scoped projects
I've worked with a lot of ORM-style libraries in several different techs and I hate them all 🙂 I've even written a couple of ORMs (and I hate those too).
i don’t hate the ones that have made me wildly productive when all i needed were basic operations
most, probably, but not all. i just learned to dial in when i would say “fine, let’s use one. doesn’t matter for this app either way.”
It's true that they can be OK for very simple CRUD stuff and in most languages they are easier than rolling your own. I haven't ever felt that in Clojure tho'. (sql/insert! ds :table map-of-data)
and (sql/get-by-id ds :table pk)
are about as simple as you can get for basic CRUD 🙂
im just saying i don’t hate the idea of some well-maintained “balance of ease > simplicity” option existing in the ecosystem
It's been interesting maintaining clojure.java.jdbc
and now next.jdbc
for nearly a decade, and HoneySQL for the last few years (can't quite remember when I took that over?).
Hmm, mid-2018. So it's been nearly three years.
Yeah, auth is an area that Clojure has always been lacking...
i cringe a bit when all i want to do is get some basic thing working with “a user logs in” and it’s like a day-long effort
again, accounting for the fact that the thing i’m working on /doesn’t need custom auth/ and won’t ever
err i can’t say that definitively, but pretend i am building an app i control 100% for the sake of argument
i would kill for a better auth story, but good auth stories wind up being good because there’s some kind of model-based thing going on, a framework is in play, whatever
at least that’s my experience… i think aaron bedra basically said this about clojure security awhile back. libraries over frameworks is great until you want to reason about some kind of unified security model.
At work, it didn't matter because we decided to write our own identity server and do oauth2 from scratch -- and that's an area that is so poorly documented! We ended up building it all on top of Apache OLTP and Jose JWT.
(and we support FB OAuth2 too -- but client-side stuff is pretty easy)
i’ve implemented things from the bits and pieces of buddy. some of those were really great experiences, and a couple were like “why am i doing this”
or messing with bouncycastle and starting to worry about holding onto the wrong thing in memory or not having the right hint in the right place
Yeah, I've looked at both Friend and Buddy and they seem... really fiddly... to work with... lots of moving parts...
all of this is to say that while i understand the philosophy because i’ve been living in it for 10+ years at this point, i’m happy to accept some stupid ORM CRUD thing every once and again and I won’t feel the least bit bad about it
i reserve the right to do things “wrong” in the same way i can create and bash on an array of int in clojure instead of using a persistent vector
If you are using Postgres you should check https://github.com/kwrooijen/gungnir it has an orm like feel and it's easy to get started.
Note that Gungnir only works with HoneySQL V1; I’m in talks with the maintainer about how to make this work with HoneySQL V2.
Walkable looks really interesting; that’s I think what I’ve been looking for from a SQL database for a long time;
Another PostgreSQL specific library providing an SQL abstraction : https://github.com/retro/penkala