[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.