This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-04
Channels
- # announcements (4)
- # aws (3)
- # babashka (58)
- # beginners (59)
- # biff (6)
- # cider (3)
- # clj-kondo (48)
- # clj-on-windows (1)
- # cljdoc (1)
- # clojure (136)
- # clojure-europe (19)
- # clojure-gamedev (7)
- # clojure-germany (2)
- # clojure-nl (7)
- # clojure-norway (1)
- # clojure-portugal (1)
- # clojure-uk (4)
- # clojurescript (41)
- # community-development (2)
- # core-async (5)
- # cursive (10)
- # data-oriented-programming (1)
- # data-science (1)
- # datahike (5)
- # datomic (60)
- # docker (2)
- # emacs (13)
- # figwheel-main (19)
- # fulcro (12)
- # graalvm (9)
- # holy-lambda (41)
- # honeysql (14)
- # introduce-yourself (3)
- # jobs (4)
- # lsp (11)
- # nrepl (1)
- # off-topic (9)
- # other-languages (2)
- # pathom (22)
- # portal (5)
- # re-frame (17)
- # remote-jobs (4)
- # reveal (14)
- # shadow-cljs (1)
- # tools-build (7)
- # tools-deps (47)
- # xtdb (8)
- # yada (2)
So the schema-on-write section mentions that only db.cardinality and db.unique can be updated. It's unclear to me if I'm allowed to transact a schema that adds in additional fields in an accreting way. Is that permitted, and if so do I have to transact the full updated schema when I add them, or can I transact only the updates?
Hey @U5NCUG8NR, you have to transact the full schema again. We have an ongoing discussion on how to handle schema updates since sometimes it is not clear how consistency can be ensured when changing something in the schema. For instance when changing db.unique
all entities previous to that transaction would have a different behavior. What kind of behavior do you expect from Datahike when migrating the schema in general? We're thinking about changing some of that functionality over the summer and insights from you might help us there.
Well for my own personal usecase I expect to only see acreting changes, that is adding new attributes. I don't expect to ever change old ones. That's definitely not an achievable constraint for all codebases, but for mine where I get to think about the problem space for a long time and don't expect to do many updates I can afford to do that. Most likely for my usecase all I'll have is a schema version attribute inserted and checked on startup and if it's less than the expected value I'll transact on it, and if it's equal continue, and if it's greater then the whole app will notify me and then crash.
Being able to transact to change single fields would mostly be useful to me if I were to do migrations from a repl.
Which is unlikely.