EventSourcingDB 1.3.0 llega con una API v2 que pone el resultado de cada petición en el cuerpo
EventSourcingDB 1.3.0 Is Available
La versión 1.3.0 de EventSourcingDB acelera la escritura y las consultas EventQL, acota en el tiempo cada petición y suma más de sesenta correcciones. Estrena una API v2 que convive con la v1, con precondiciones recursivas, errores identificados por código y respuestas en streaming que cierran con un ítem explícito. También añade exportación e importación sin conversión, copias incrementales y límites de tasa activados por defecto. La v1 seguirá disponible hasta el 31 de enero de 2027.
Una vez que el servidor ha aceptado una petición, su resultado está en el cuerpo.
- bythreads
Nunca he trabajado en unas operaciones de TI donde las habilidades de los desarrolladores fueran lo bastante altas como para usar eventsourcing — bueno sobre el papel y para neckbeards — ningún junior puede programar contra eso
- zbentley
EventQL parece agradable, pero
> Mientras se evalúa una precondición de EventQL, toda otra escritura espera, de modo que nada pueda colarse en medio; las lecturas siguen mientras tanto. Para que ninguna escritura retenga a las demás por mucho tiempo, las precondiciones de EventQL de una escritura se evalúan durante un máximo de cinco segundos, todas juntas, contados desde que la escritura obtiene su turno: una escritura cuyas precondiciones tarden más es rechazada, sin escribir nada, con un 400
(De https://www.eventfoundation.io/docs/eventsourcingdb/precondi...)
Eso parece un enorme foot gun. O sea, claro, no tienes que implementar semántica transaccional ni pensar en consistencia/MVCC/snapshots. Pero ¿a costa de que "cada UPDATE ... WHERE bloquee toda otra escritura hasta por 5 segundos"? ¿En serio?
Eso parece un mal tradeoff, inferior tanto a (esfuerzo masivo) implementar una transaccionalidad adecuada, (esfuerzo medio, pero rompiendo significativamente la compatibilidad) eliminar el soporte para sujetos anidados jerárquicamente de modo que las restricciones de mutex global sobre UPDATE-WHERE puedan levantarse o acotarse eficientemente a un sujeto, o (menor esfuerzo) eliminar por completo el soporte para precondiciones de EventQL. En cualquier sistema suficientemente grande o con múltiples desarrolladores no me imagino que "no uses precondiciones de EventQL" vaya a mantenerse de forma efectiva.
Tal como está, siento que tener el sistema principal de event sourcing bloqueado hasta 5 segundos por la lenta precondición de EventQL de un solo cliente es pedir a gritos eventos de caída generalizados de la nada.
Dicho esto, puede que me esté perdiendo algo que lo palíe aun así […]
- chaostheory
Esto puede ser útil para agentes personales donde quieres almacenar memorias o "pensamientos" de la vida y el trabajo de una persona corriendo en una sola máquina para evitar la deriva o las alucinaciones… pero la licencia no hace esto factible