This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # beginners (8)
- # calva (17)
- # cider (3)
- # clj-kondo (1)
- # cljs-dev (7)
- # clojure (11)
- # clojure-dev (9)
- # clojure-europe (1)
- # clojuredesign-podcast (4)
- # clojurescript (10)
- # conjure (13)
- # datomic (3)
- # emacs (3)
- # figwheel-main (1)
- # fulcro (12)
- # leiningen (8)
- # meander (20)
- # off-topic (85)
- # pathom (1)
- # shadow-cljs (39)
- # spacemacs (7)
- # tools-deps (44)
- # xtdb (5)
Hi folks, quick question/survey: If you were not allowed to use Clojure when working on a backend application (non-user-facing) what language would you choose? In other words, what's your first alternative to Clojure?
i'm writing interop code database glue code and i find myself repeating some patterns for every model/entity type when i define its basic CRUD operations. i want to write a macro to tame this but my only thought is to write a monolithic
defmodel macro which would have a bunch of def[n]s in it, which i think isn't looked upon very favorably in general since it obscures the vars that are being defined. does anyone have a recommendation for how to approach this?
@lgessler It sounds a bit like you're leaning toward ORM-style code, which I would expect to be somewhat repetitive. When I'm doing CRUD, I tend to just have
(insert! ds :table some-record),
(get-by-id ds :table pk) or
(find-by-keys ds :table example-map),
(update! ds :table set-map example-map), and
(delete! ds :table example-map) and that covers the vast majority of cases. No repetitive code.
After all, Clojure is all hash maps, rather than "model/entity type", and both
next.jdbc traffic in hash maps directly.
right, that's definitely the approach i tend to favor, i'm trying to understand why i want to reach for something more ORM-y... i think what's getting me here is that i want to sometimes do different/additional operations when i do a write on a model, but maybe that just means it's business logic that ought to go into a different layer of abstraction
Sounds plausible. I generally try to have as thin a layer for persistence as possible -- pretty much just raw CRUD on hash maps if I can -- and then everything else is business logic. Of course there are some situations where you absolutely need to leverage some of the atomic features of a database and/or perform aggregation in the database etc, but those things are "outside" CRUD anyway so having some actual code around them is fine (and should be the exception, rather than the rule).
If it's any consolation, when I first started using Clojure, I tended to write vaguely ORM-style wrappers around c.j.j but I fairly quickly stopped doing that (because it was repetitive and also tended to be a bit "brittle" in the face of schema changes -- trafficking in hash maps means the actual persistence part, those four/five simple CRUD calls, remains simple because the code doesn't care about what is in the maps).