I confess I haven't used Datomic but some good places to start understanding XTDB's model wrt Bitemporality might be: • https://docs.xtdb.com/intro/data-model.html • https://docs.xtdb.com/reference/main/xtql/queries.html#_temporal_filters

@U057T406Y15 Could you summarize that post/thread you linked to? Only members of that Google Group can read it.

It's a thread talking about the difficulties of integrating datomic and business time. Rich and Stu participate in that thread and share their thoughts regarding the problems involving cache, retractions and indexes, and I'm wondering how XTDB addresses these issues, in other words, how does xtdb excels where datomic fails? what are the design and architectural tradeoffs?

You might want to read some of Kent Beck's recent writing on bitemporality where he talks about the business issues (unrelated to XTDB) - and then after that listen to the interview the XTDB team did with him (because he'd been talking about bitemporality).

https://tidyfirst.substack.com/p/eventual-business-consistency

That is one of Kent's pieces but he wrote several on that blog.

This is the interview: https://www.juxt.pro/blog/kent-beck-podcast/

And you might find this useful reading: https://www.juxt.pro/blog/bitemporal-webinar-q-and-a/

Great! thanks a lot I'll into that

> We are interested in understanding more about XTDB and its model, where can we find design sources? > Specifically, how does XTDB addresses these issues that Datomic doesn't support? > [...] > how XTDB addresses these issues, in other words, how does xtdb excels where datomic fails? what are the design and architectural tradeoffs? we will write up more on this area in the XT2 docs in due course, but the essential answer is that XT (1.x and 2.x alike) have always had a simpler data and indexing model than Datomic, in particular with a central principle of filtering out irrelevant history (such that querying the transaction-time past necessarily slows as the database grows) rather than relying on persistent, immutable B-tree snapshot references (with T as the last element in the index structure... this is worth a read https://tonsky.me/blog/unofficial-guide-to-datomic-internals/). But XT is really very different, and XT2 in particular is designed for much better "scan"/OLAP performance than anything XT1 or Datomic could offer

#error {:cause nil,
        :data {:class "java.lang.StackOverflowError",
               :stringified "java.lang.StackOverflowError",
               :xtdb.error/error-type :unknown-runtime-error},
        :trace
          [[xtdb.serde$fn__26045 invokeStatic "serde.clj" 159] [xtdb.serde$fn__26045 invoke "serde.clj" 159]
           [cognitect.transit$read_handler$reify__3340 fromRep "transit.clj" 181]
           [com.cognitect.transit.impl.JsonParser parseArray "JsonParser.java" 143]
           [com.cognitect.transit.impl.JsonParser parseVal "JsonParser.java" 56]
           [com.cognitect.transit.impl.JsonParser parse "JsonParser.java" 46]
           [com.cognitect.transit.impl.ReaderFactory$ReaderImpl read "ReaderFactory.java" 112]
           [cognitect.transit$read invokeStatic "transit.clj" 323] [cognitect.transit$read invoke "transit.clj" 319]
           [xtdb.client.impl$eval43414$fn__43416$parse_body__43418 invoke "impl.clj" 76]
           [xtdb.client.impl$eval43414$fn__43416 invoke "impl.clj" 85] [clojure.lang.MultiFn invoke "MultiFn.java" 234]

Hi Sean, this looks like https://github.com/xtdb/xtdb/issues/3065 in this case but in future it looks like filing issues is still fine just make it clear you're on v2 🙂

@U050V1N74 is that right?

Cool. I wasn't sure if there was a preferred forum or other "gating" approach, rather than just creating issues directly on GH!

Doesn't seem so 🙂 Business as usual!