This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-04
Channels
- # babashka (17)
- # beginners (82)
- # calva (42)
- # clj-commons (9)
- # cljdoc (2)
- # cljsrn (3)
- # clojure (142)
- # clojure-europe (12)
- # clojure-nl (1)
- # clojure-sg (1)
- # clojure-uk (14)
- # clojurescript (22)
- # community-development (3)
- # cryogen (12)
- # cursive (15)
- # data-science (13)
- # datomic (11)
- # deps-new (8)
- # emacs (3)
- # fulcro (31)
- # gratitude (7)
- # holy-lambda (8)
- # honeysql (6)
- # introduce-yourself (1)
- # jackdaw (11)
- # jobs-discuss (7)
- # kaocha (1)
- # malli (8)
- # other-languages (9)
- # pathom (14)
- # pedestal (1)
- # polylith (3)
- # portal (12)
- # re-frame (3)
- # react (3)
- # reagent (4)
- # releases (3)
- # reveal (7)
- # ring (11)
- # shadow-cljs (17)
- # specter (3)
- # sql (1)
- # timbre (2)
- # tools-deps (122)
- # xtdb (18)
Is there a real difference between delete vs put a doc with the same entity but no attributes? The advantage of the latter is that you can do metadata like stuff (who deleted this) as part of the doc itself
the latter may still join against values which reference its entity id; the former won't
also, match will treat the two differently - whether that's a 'real difference' depends on your use case 🙂
ah, that's true. I've commited to the entity IDs having no semantic meaning whatsoever so that's mitigated. Match is a tougher problem since ideally you'd probably want it to ignore metadata, although maybe it'd be helpful to match on metadata sometimes.. but there's always tx fns
I guess it could be a performance issue to join on things that would otherwise be skipped with delete?
or I could still do the metadata doc, AND the delete op in the same tx.. cake and eat it too?
Wasn't there an issue about put and delete to the same entity in the same tx? Or was that evict
does evict have any implications for tx log replay? eg. if there's a tx function that does different things based on what is found at the time... or are the end results of the tx fn stored in the tx log?
ah, I see what you mean, my mistake - it's a nuance around what actually goes on the tx-log when it comes to tx-fns we assume that the arguments to a transaction function could potentially have personally-identifiable information in, so when a tx-fn is invoked, we split the invocation up into the function to be invoked and the arguments. the arguments go into a document in the doc-store, and a reference to the arg-doc included in the entry on the tx-log (not dissimilar to normal put operations) it's the content of this arguments doc that's then replaced with the result of the tx-fn invocation
replaced by every node that indexes the tx concurrently - this is why it's important that tx-fns are deterministic, so that the subsequent updates are idempotent