Discussion over integrating with XTDB

[hnaderi]

Hi @hnaderi,
Thank you for your support! I think about integrating Edomata Event Sourcing model with a Bi-temporal Database like "XTDB". What do you think about it? There is no open-source FSM library that support bi-temporal sourcing and queries. Edomata could be best option to do this. Please help us with examples to develop Edomata with XTDB queries!!

Originally posted by @BNationsDEV in #108 (comment)

https://docs.xtdb.com/concepts/trucks-tubes-truth/

[hnaderi]

https://docs.xtdb.com/concepts/trucks-tubes-truth/

By the way, it was an interesting read, Thank you!

What are your ideas on how this can be achieved? @BNationsDEV

[BNationsDEV]

Hi,

Yes, it could be great if we could success to apply bi-temporality patterns with Edomata. I will summarize my ideas after i collect more info and try to design an architecture in next days.

Also these resources are helpful;

https://martinfowler.com/articles/bitemporal-history.html
https://www.youtube.com/watch?v=xzekp1RuZbM
https://techleadjournal.dev/episodes/66/
https://www.youtube.com/watch?v=YjAVsvYGbuU&t=1500s
https://www.youtube.com/watch?v=m8dhHcrYaGk
https://solid.jobs/blogs/better-software-design-47-o-nauce-ddd-i-bitemporalnych-eventach-domenowych-z-andrzejem-krzywda
https://github.com/RecallGraph/RecallGraph

[BNationsDEV]

Other resources;
https://vvvvalvalval.github.io/posts/2018-11-12-datomic-event-sourcing-without-the-hassle.html

https://blog.arkency.com/fixing-the-past-and-dealing-with-the-future-using-bi-temporal-eventsourcing/

[BNationsDEV]

Integrating Edomata's persistance/storage layer with a bi-temporal graph database will give new abilities to us;

1. Space-time ability. We will be able to travel in times with FSM mechanism. So it will let us to replay behaiovurs of point-in-time.
2. By using a bi-temporal graph data model; we will able to save snapshots and events in document model that supports graph queries. It will increase query performance and will give new query abilities with the powers of graph architecture
3. We will no need to database schemas to write records. XTDB supports schema-less document store features. So it will be a generic solution to store records and query them with graph ability.
4. XTDB is immutable. An ideal FSM mechanism needs trust. Immutability will give us more trust.
5. And more...

Additional note;
I suggest integrating XTDB with Edomata but we could choose another database solution that provide us these capabilities;

1. Bi-temporality
2. Immutable
3. Document data model to store events and snapshots with a generic architecture
4. Graph query engine
5. Relational query model
6. Schema-less data model
7. ACID transactions support

[BNationsDEV]

XTDB has a continues roadmap to develop new database engine;
https://xtdb.com/core2/
https://github.com/xtdb/core2

It's not production ready yet but it supports SQL:2011.
https://en.wikipedia.org/wiki/SQL:2011

[hnaderi]

Adding a storage driver for XTDB, that requires events to be bitemporal (have an optional valid-time metadata) seems to be enough for adding support for XTDB, and it seems to be easy as well.
What do you think about this suggestion?

There is only one requirement which I'm not yet sure whether or not can be implemented in XTDB, and that's the optimistic version lock used on event versions per stream, so that concurrent updates are detected and retried by the backend.
Do you know whether it can be implemented or not?