This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-18
Channels
- # adventofcode (326)
- # aws (1)
- # beginners (67)
- # cider (52)
- # cljs-dev (5)
- # cljsrn (5)
- # clojure (104)
- # clojure-art (2)
- # clojure-austin (34)
- # clojure-france (12)
- # clojure-greece (38)
- # clojure-india (2)
- # clojure-italy (6)
- # clojure-spec (11)
- # clojure-uk (32)
- # clojurescript (51)
- # core-async (5)
- # cursive (11)
- # data-science (5)
- # datascript (3)
- # datomic (3)
- # defnpodcast (7)
- # fulcro (26)
- # graphql (10)
- # hoplon (1)
- # instaparse (2)
- # jobs (1)
- # klipse (3)
- # lumo (13)
- # off-topic (50)
- # om (2)
- # onyx (19)
- # parinfer (1)
- # pedestal (4)
- # re-frame (18)
- # ring-swagger (1)
- # spacemacs (1)
- # specter (42)
- # sql (9)
- # uncomplicate (18)
- # unrepl (13)
@sova any reason why you wouldn’t have the relationship blurb -> tag be of cardinality many?… as in 1 blurb -> n tags -> 1 author
@sova A lot depends on what you'll use the tags for. If they're just for discoverability I'm not sure they need authors or an identity of their own. I agree with luchini that by default I'd make tags a cardinality/many string attribute of the blurb.
The "intermediate states" issue, if I understand it correctly, sounds solvable by putting the blurb and tags into a single transact
statement using tempids to define the cross-references between yet-to-be-created entities. (If tags become instead merely a string attribute of blurbs, this becomes unnecessary.)