This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-25
Channels
- # babashka (31)
- # beginners (38)
- # biff (1)
- # calva (10)
- # clj-kondo (10)
- # clj-otel (9)
- # clojure (9)
- # clojure-europe (4)
- # clojure-norway (4)
- # clojurescript (26)
- # cursive (2)
- # datahike (3)
- # datomic (4)
- # emacs (6)
- # inf-clojure (2)
- # missionary (11)
- # nbb (3)
- # off-topic (9)
- # portal (17)
- # re-frame (16)
- # reagent (1)
- # releases (3)
- # shadow-cljs (5)
- # tools-build (17)
- # tools-deps (2)
- # xtdb (6)
I wouldn't really. It's temporal, but it's not straightforward to add data in the past (without rebasing all future changes)
That's more of a problem with git core entities being changes, not states. The changes won't work, if the starting state changes. I would see the bitemporality more like merging in an old commit. Then you can ask for example the state of the main branch yesterday, which didn't know about some changes that were merged today.
Of course the problem is that nothing guarantees that the main branch wasn't pushed from a completely different commit tree, and hasn't been incrementally grown. But you could argue that someone could also just rebuild the xtdb history too, with modifications
Converting a Git repo to an XT database is a kind of interesting challenge. Would force deciding how to handle rebasing, etc.
Incidentally, I noticed that git 2.37 has a new --since-as-filter that will really check for all changes since given date, unlike --since which will stop traversing the tree after the first time it hits a commit that is too old. Places where it shows that while git in principle could be handled as a temporal store, the tooling isn't really designed to work from that point of view for anything more than the simplest cases.
Incidentally, I noticed that git 2.37 has a new --since-as-filter that will really check for all changes since given date, unlike --since which will stop traversing the tree after the first time it hits a commit that is too old. Places where it shows that while git in principle could be handled as a temporal store, the tooling isn't really designed to work from that point of view for anything more than the simplest cases.