22 points goloroden 3 hours ago 1 comments
zbentley 4 minutes ago | parent
> 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.