EventSourcingDB 1.3.0 стал заметно быстрее и получил новый API
EventSourcingDB 1.3.0 Is Available
Вышла версия EventSourcingDB 1.3.0: запись, чтение и EventQL-запросы работают значительно быстрее, а каждый запрос теперь ограничен по времени. Появился API v2, который возвращает результат в теле ответа и присваивает каждой ошибке собственный код со ссылкой на страницу с объяснением. Старый API v1 поддерживается до 31 января 2027 года. Добавлены инкрементальные бэкапы, экспорт и импорт без преобразований, рекурсивные предусловия и rate limiting по умолчанию. Перед обновлением обязательно сделайте резервную копию: данные, открытые версией 1.3, больше не откроются в старых версиях.
Каждый запрос, каждый ответ и каждое простаивающее соединение ограничены по времени, так что медленный или зависший клиент больше не может удерживать ресурсы бесконечно.
- bythreads
Я никогда не работал в IT-операциях, где квалификация разработчиков была бы достаточно высокой для использования eventsourcing — хорошо на бумаге и для бородачей — ни один джун не сможет писать под это.
- zbentley
EventQL кажется неплохим, но
> Пока выполняется предусловие EventQL, все остальные записи ждут, так что ничего не может вклиниться; чтения тем временем продолжаются. Чтобы ни одна запись надолго не задерживала другие, предусловия EventQL для записи вычисляются не более пяти секунд, все вместе, считая с момента, когда запись получает очередь: запись, чьи предусловия выполняются дольше, отклоняется, ничего не записывается, с кодом 400
(Из https://www.eventfoundation.io/docs/eventsourcingdb/precondi...)
Это выглядит как огромная ловушка. Мол, конечно, вам не нужно реализовывать транзакционную семантику или думать о согласованности/MVCC/снимках. Но ценой того, что "каждый UPDATE ... WHERE блокирует все остальные записи на срок до 5 секунд"? Серьёзно?
Это кажется плохим компромиссом, уступающим как (огромные усилия) реализации полноценной транзакционности, так и (средние усилия, но значительное нарушение совместимости) удалению поддержки иерархически вложенных субъектов, чтобы можно было снять ограничения глобальной блокировки на UPDATE-WHERE или эффективно ограничить их одним субъектом, или (наименьшие усилия) полному удалению поддержки предусловий EventQL. В любой достаточно большой системе с множеством разработчиков я не представляю, что "не используйте предусловия EventQL" реально приживётся.
Как есть, я чувствую, что блокировка основной системы event sourcing на срок до 5 секунд из-за медленного предусловия EventQL одного клиента — это заявка на повсеместные простои из ниоткуда.
Тем не менее, возможно, я упускаю что-то, что смягчает это […]
- chaostheory
Это может быть полезно для персональных агентов, где вы хотите хранить воспоминания или «мысли» для жизни и работы одного человека, работающих на одной машине, чтобы предотвратить дрейф или галлюцинации… но лицензирование не делает это осуществимым.