This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-22
Channels
- # announcements (88)
- # autochrome-github (2)
- # babashka (26)
- # beginners (5)
- # biff (2)
- # cider (73)
- # clj-kondo (4)
- # cljsrn (6)
- # clojure (54)
- # clojure-art (3)
- # clojure-europe (73)
- # clojure-germany (5)
- # clojure-new-zealand (1)
- # clojure-nl (13)
- # clojure-norway (16)
- # clojure-uk (8)
- # clojurescript (73)
- # conjure (1)
- # core-async (10)
- # cursive (17)
- # datahike (51)
- # datalevin (21)
- # datomic (4)
- # emacs (2)
- # events (3)
- # fulcro (35)
- # honeysql (6)
- # introduce-yourself (1)
- # jackdaw (3)
- # jobs (1)
- # leiningen (4)
- # lsp (3)
- # malli (17)
- # off-topic (60)
- # other-languages (5)
- # pathom (17)
- # pedestal (3)
- # polylith (19)
- # portal (2)
- # practicalli (1)
- # rdf (14)
- # reitit (3)
- # releases (1)
- # reveal (9)
- # sci (1)
- # shadow-cljs (26)
- # spacemacs (17)
- # sql (4)
- # testing (10)
- # tools-build (6)
- # tools-deps (16)
- # vim (9)
Are there any helper functions for reshaping a SELECT + JOIN query to nest the joined columns under a key at the root?
For example, given a Pet with a single Owner, we have a select on Pet select * from pet inner join owner on owner.id = pet.owner_id
, and I'd like to reshape the flat map returned by the query into a map such as { :pet/id 1 :pet/owner { :owner/id 1 :owner/name "Alice" } }
I know this isn't next.jdbc's core area, but with all the other little helpers I thought there might be such a fn.
@ramblurr Such a thing would always be very domain-specific although I think a few people have written functions to coalesce result sets based on keys/namespaces -- but 1:1 and 1:many look pretty different and you can't deduce that from the shape of the data in general so those relationships have to be "hinted" somehow through parameters.
The request comes up from time to time and I've given it some thought. I'll open an issue to track it because I think I might have enough examples in mind now to figure out something that would probably cover most cases (covering 100% is likely to be hard). https://github.com/seancorfield/next-jdbc/issues/201