EventSourcingDB 1.3 ships a new API and makes every request time-bounded
EventSourcingDB 1.3.0 Is Available
EventSourcingDB 1.3.0 brings a v2 API that returns every accepted request's outcome in the body, with each error carrying a code that links to its own documentation page. The release also makes writing and EventQL queries considerably faster, bounds every request and idle connection in time, and adds incremental backups, rate limiting, and OpenMetrics health reporting. The v1 API remains supported until January 31, 2027, so upgrades can proceed at your own pace.
Once the server has accepted a request, its outcome is in the body.
- bythreads
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
- zbentley
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 tho […]
- chaostheory
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