[rads]

In practice I do wrap `jdbc/execute!` with my own `execute!` function to set some default options. However, there is no ORM layer. What makes you think the code above is terribly unproductive?

Edit: Not trying to dismiss your concerns, by the way. In Clojure you can often get away with doing less than you might think so I'm genuinely curious about the critique.

[winrid]

In Django I would just do Posts.objects.filter(title=x)

I don't need to define driver boilerplate for every query (or ever have to write it... at all).

[didibus]

In Clojure you'll have to write the queries yourself unfortunately. People always ask, where is the fully fledged web framework in Clojure? There isn't one. Why there isn't one is hard to answer, but it's partially because the people who could write one, don't find they need one themselves.

There's definitely a preference in Clojure for not relying on frameworks, because the current people in the community like to be in control, know what's going on, or do it their own way.

That said, the whole code still ends up being relatively small. So, you kind of end up with a similar amount of total code, but you're much more in control. And if certain things you find too repetitive, you can remove the repetition yourself through many of Clojure's facilities, specifically where they annoyed you.

See: https://github.com/didibus/simple-website-with-posts where I implemented the small website you were talking about, creating posts and seeing them. The whole code is here (minus the CSS): https://github.com/didibus/simple-website-with-posts/blob/ma...

It's 95 loc and that includes the templates. There's no framework.

[winrid]

> I implemented the small website you were talking about

Thanks, that's neat.

I'm not even talking about the framework part. Just db access. Let's say I have a Posts with a managed_by property that points to a list of User which have a ManagedProfile. In Django's ORM (or any good ORM), I could do:

if post.managed_by.contains(user.managedProfile)...

or I could do:

post.managed_by.add(user.managedProfile)

also all these tables and join tables are generated by just a few lines of model definitions.

I'm still in control. I am writing the code. I get to choose when I do slow and fast stuff. Not having these features isn't "more control" it's less features. :P

I still see the benefits of Clojure, though!

[didibus]

Ya, so you'll be working with the DB directly instead of through an Object representation.

And I agree with you, it's less features, and maybe it would be nice to have something similar in Clojure, but there's a reason the feature doesn't feel as needed, and nobody bothered building it.

In OO langs, one of the major pain points the ORM solves is mapping the result back into an Object. Otherwise, you have to manually go:

  post = new Post();
  post.title = queryResult[1];
  post.content = queryResult[2];
  ...

In fact, some ORM keep to that only, I think are normally called micro-ORMs. All they do is data mapping to/from between the DB and your object model.

In Clojure, you don't have this pain point, the DB query returns a list of maps, and you work with those maps directly.

I suspect this is the main reason why no one bothers implementing an ORM-like in Clojure.

That means, for your example, you would create a function that queries the DB to check if a post is managed by a particular user. And you'd call that for your condition:

  (if (is-managed-by? post-id user-id) ... ...)

Or to add one you'd do something similar, create a function that adds a user to manage a post:

  (add-manager-to-post post-id user-id)

You're working directly with IDs, because there are no Objects here. You're working with data directly, and that data is similar to the data in your DB, the representation is much closer between what your code uses and the DB.

That means, in OO langs, you think of your state as being those object models, and then you try to sync them back/forth to the DB, after you've mutated it a bunch, you call .save() on it for example. But in Clojure, you think of your state as the DB itself, if you want to change state, you just run a query on the DB to change that state directly, you don't modify some in-memory model and then try to sync that back to the DB.

[rads]

The key thing is experienced Clojure programmers often see a lack of ORM as a feature rather than an oversight. There were some more ORM-like libraries years ago (see Korma) but my impression is that people ultimately didn't want this and moved on to lower-level JDBC wrappers combined with HoneySQL. I found a more detailed discussion on Reddit about Clojure and ORMs back in 2020 if you want to get more info: https://reddit.com/r/Clojure/comments/g7qyoy/why_does_orm_ha...

Note that I'm not making a value judgement about Python/Django or any other library/framework combination. It's obviously a valid path, but Clojure is a different path. I can assure you there are straightforward solutions to create readable APIs like the Django example with minimal boilerplate, but the approach is fundamentally different from Python/Django.

If you do decide to build something in Clojure and think, "I already know how to do this in Django, why is it missing?", don't hesitate to join the Clojurians Slack and hop into the #beginners channel. There are plenty of people who can help you there.