EventSourcingDB 1.3.0 Is Available

I have never worked in an it operations where the skills of the developers was high enough to use eventsourcing - good on paper and for neckbeards - no junior can code up against it

EventQL seems nice, but

> While an EventQL precondition is evaluated, every other write waits, so that nothing can come in between; reads go on meanwhile. So that no write holds up the others for long, the EventQL preconditions of a write are evaluated for at most five seconds, all of them together, counted from when the write gets its turn: a write whose preconditions take longer is rejected, with nothing written, with a 400

(From https://www.eventfoundation.io/docs/eventsourcingdb/precondi...)

That seems like a huge foot gun. Like, sure, you don't have to implement transactional semantics or think about consistency/MVCC/snapshots. But at the cost of "every UPDATE ... WHERE prevents every other write for up to 5 seconds"? Really?

That seems like a bad tradeoff, inferior to both (massive effort) implementing proper transactionality, (medium efffort, but significantly compatibility-breaking) removing support for hierarchically-nested subjects so that the global-mutex restrictions on UPDATE-WHERE can be lifted/efficiently scoped to a subject, or (lowest effort) removing support for EventQL preconditions entirely. In any sufficiently large/multi-developer system I don't imagine that "don't use EventQL preconditions" will effectively stick.

As it is, I feel like having the main event sourcing system blocked for up to 5sec on any one client's slow EventQL precondition is asking for pervasive downtime events out of nowhere.

That said, I may be missing something that ameliorates those issues! I'm just skimming docs, so take it with a grain of salt.

This can be useful for personal agents where you want to store memories or “thoughts” for one person’s life and work running on one machine to prevent drift or hallucinations… but the licensing does not make this feasible