This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-25
Channels
- # architecture (12)
- # asami (6)
- # aws (2)
- # babashka (2)
- # beginners (71)
- # bristol-clojurians (1)
- # calva (1)
- # cider (2)
- # clojure (136)
- # clojure-australia (6)
- # clojure-dev (14)
- # clojure-europe (11)
- # clojure-italy (3)
- # clojure-nl (2)
- # clojure-sanfrancisco (29)
- # clojure-uk (9)
- # clojuredesign-podcast (12)
- # clojurescript (23)
- # code-reviews (7)
- # core-logic (5)
- # cryogen (7)
- # datomic (7)
- # depstar (7)
- # events (3)
- # fulcro (11)
- # helix (1)
- # jobs (2)
- # juxt (4)
- # kaocha (25)
- # leiningen (2)
- # malli (11)
- # off-topic (8)
- # pathom (1)
- # pedestal (9)
- # portkey (1)
- # reitit (3)
- # ring (2)
- # sci (46)
- # shadow-cljs (21)
- # tools-deps (15)
- # xtdb (31)
I noticed attribute predicates check explicitly retracted values (from user-supplied tx data or tx-fn expansions) but not implicitly retracted values (from cardinality-one attributes with a new assertion). 1) Why check retractions at all? 2) Why this difference? I’m observing this on on-prem 1.0.6165 if it makes a difference.
I would prefer that attribute predicates are never run on retracted values as it makes it much easier to migrate to cleaned-up values. In our case we’re installing string length limits, and would be ok with old values being too long as long as new values are not.
It also means we need some kind of atomic tx fn to install an attribute predicate safely.
might be better to log this at https://ask.datomic.com ...
standard support channels are best, then ask.datomic as it creates a searchable archived record for the future, and then here is good for conversation but checked less frequently than the above