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.
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:
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:
Or to add one you'd do something similar, create a function that adds a user to manage a post: 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.