This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-03
Channels
- # beginners (167)
- # boot (22)
- # chestnut (3)
- # cider (9)
- # clojure (107)
- # clojure-berlin (1)
- # clojure-greece (3)
- # clojure-italy (6)
- # clojure-losangeles (6)
- # clojure-russia (8)
- # clojure-spec (71)
- # clojure-uk (42)
- # clojurescript (186)
- # community-development (1)
- # core-async (12)
- # core-typed (1)
- # css (15)
- # cursive (29)
- # data-science (11)
- # datomic (8)
- # defnpodcast (28)
- # duct (2)
- # fulcro (169)
- # graphql (6)
- # hoplon (3)
- # jobs-discuss (1)
- # kekkonen (5)
- # leiningen (11)
- # lumo (7)
- # off-topic (14)
- # om (1)
- # other-languages (14)
- # portkey (7)
- # re-frame (27)
- # reagent (14)
- # remote-jobs (1)
- # ring-swagger (5)
- # rum (15)
- # shadow-cljs (52)
- # spacemacs (59)
- # specter (78)
- # test-check (3)
- # vim (9)
- # yada (23)
@djjolicoeur Hmm, ok. So does it make sense to give A a list of B refs (cardinality/many), or give each B a ref to A?
@ghopper it depends on how you are going to use it. I personally prefer a :cardinality/one
from each B to A in most cases, given that I can get that many relation via the reverse reference on A. I just find it to be cleaner to maintain from B. My personal preference is that, if the ref is not a component entity of A, then the ref goes from B to A. I'm sure some folks may disagree with that, though.
Ok, that's helpful. Thank you
@djjolicoeur Component entity meaning all Bs are deleted when A is deleted?
Only if it's marked as such, of course.
yes, that would be a consequence of having a ref from A to B where :db/isComponent
is true
.
Ok, and that could only be done with a one to many from A to Bs. Makes sense. :thumbsup: