Clojurians Log v2

@martinklepsch Here's a cute code-golf-y solution: (->> (range) (map #(quot % 3)) (partition 3 1) (map reverse) (take 10)) That said, while this is slightly more succinct, I much prefer @oscarlinusericsson’s version as it conveys the semantics of the intended operation much better.

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

next.jdbc is the library to use with anything else

thats not an abstraction layer really, but still worth mentioning

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)

@matheusashton Feel free to drop into the #sql channel to discuss in more depth. There's also #honeysql #hugsql #walkable

what are the latest ORM-y situations in Clojure?

still Korma? I guess you mentioned Toucan, not familiar with it

Toucan looks kind of neat

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 🙂

fwiw, i’ve played the korma game and i won, but it was a small personal project

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

toy projects or projects with long-term obviously limited scope

i’ve been bitten, but i definitely can’t say all of them were bad experiences

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 🙂

yeah, it’s a fair point

im just saying i don’t hate the idea of some well-maintained “balance of ease > simplicity” option existing in the ecosystem

because depending on the project i could see myself reaching for it

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.

one common case i can’t ignore: Rails’ Devise is so incredibly easy for auth

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 still have a project using friend in prod

i don’t really want to talk about that code tho, tbqh

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

“consenting adults language” and all that is a phrase worth remembering

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

preference is one thing, but I am happy to make the occasional tradeoff, depending

</rant>

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.