This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-29
Channels
- # announcements (3)
- # babashka (47)
- # beginners (88)
- # calva (17)
- # clj-kondo (8)
- # cljdoc (1)
- # clojars (9)
- # clojure (98)
- # clojure-europe (53)
- # clojure-norway (2)
- # clojure-seattle (1)
- # clojure-uk (5)
- # clojurescript (20)
- # cursive (11)
- # data-oriented-programming (1)
- # data-science (3)
- # datahike (1)
- # datascript (3)
- # events (3)
- # graalvm (5)
- # honeysql (7)
- # hyperfiddle (1)
- # jobs-discuss (10)
- # leiningen (3)
- # malli (16)
- # music (4)
- # nbb (17)
- # off-topic (45)
- # pathom (9)
- # portal (7)
- # releases (1)
- # shadow-cljs (80)
- # sql (15)
- # tools-build (5)
- # xtdb (23)
What is the way to use Pathom with a fully normalized SQL database that uses natural composite primary keys instead of surrogate keys (uuids)? Is it more pragmatic to just add a UUID column and use that?
with pathom3 placeholders https://pathom3.wsscode.com/docs/placeholders/#provide-data Should be more natural to pass multiple parameters when asking for an attribute for example
[{(:>/user {:user/username "souenzzo" :user/org-id "clojurians"})
[:user/name
:user/email]}]
With this query, you should be able to create a resolver that receives :user/username
and :user/org-id
, and lookup in the DB using the composite key.there is nothing stopping you from having a composite value in ident.
{[:user/composite-id ["souenzzo" "clojurians]] [:user/name]}
@U2J4FRT2T thank you for the suggesting to use placeholders for this. I'll take a look at that approach. I understand that your ident value can be anything and that this makes using composite keys possible. I am wondering whether this is a good approach to take in practice instead of just using a uuid. Sometimes the composite PKs can be quite a number of fields - I think technically up to 32 or so - and while passing around the whole composite key would have technical merit, most of my pre-clojure experience is with Django, where using a UUID instead of a composite key is the standard practice and mostly works okay. There's an open 17 year old https://code.djangoproject.com/ticket/373 about it in the tracker 😄 Have you guys tried both ways? If so, did any significant tradeoffs lead you to prefer one option over the other?
I mean i have never worked with such a massive amount of components in a key mostly 2 or 3
As far as software goes there really isn’t much of a difference between putting 32 keys into a placeholder or ident