Présentation de la version 1.3.0

EventSourcingDB 1.3.0 arrive avec plus de soixante correctifs et des gains de vitesse sur l’écriture, la lecture et les requêtes EventQL. Chaque requête est désormais limitée dans le temps, ce qui empêche un client lent de monopoliser les ressources. La documentation a été déplacée sur eventfoundation.io, tous les anciens liens y redirigent automatiquement.

Architecture de l’API v2 et gestion des erreurs

Le nouveau v2 API fonctionne en parallèle du v1 jusqu’au 31 janvier 2027. Il renvoie le résultat de chaque requête dans le corps de la réponse, dès que l’authentification, la forme du corps et les limites sont respectées. En cas d’échec, un code d’erreur dédié est fourni, chaque code pointant vers une page explicative. Les flux de lecture se terminent par un élément end explicite et le serveur envoie des battements de cœur pour éviter la fermeture par les proxys.

Les préconditions récursives isSubjectPristine, isSubjectPopulated et isSubjectOnEventId peuvent s’appliquer à un sujet et à tous ses descendants, ce qui simplifie les décisions dépendant d’une sous‑arborescence complète.

--require-event-schemas

Ce nouveau drapeau, désactivé par défaut, refuse les écritures dont le type d’événement n’a pas de schéma enregistré.

Optimisations de performance et résilience

Les écritures sont plus rapides même sous forte charge, et les requêtes EventQL qui lisent, regroupent, trient ou joignent de nombreux événements gagnent en rapidité. Les index occupent moins de fichiers, ce qui accélère la lecture d’un sujet dans de grandes bases. La vérification d’intégrité signale désormais jusqu’à cent incohérences au lieu d’une seule.

Les limites de requêtes EventQL contrôlent la profondeur d’imbrication et la consommation mémoire, évitant les débordements de pile. Le serveur compare les jetons d’API en temps constant et passe en mode lecture‑seule si l’écriture échoue (par ex. disque plein), tout en exposant la cause via le point de santé OpenMetrics, exploitable par Prometheus.

Consignes de migration et limites

Avant de passer à 1.3, il faut sauvegarder les données : le répertoire ouvert par 1.3 ne peut plus être lu par une version antérieure. Il faut arrêter l’ancien serveur, car les versions ≤ 1.2 ne verrouillent pas le répertoire, ce qui rendrait impossible un déploiement RollingUpdate sans corruption.

Le conteneur Docker utilise désormais l’UID 65532 au lieu de 100 ; les permissions du répertoire doivent être transférées une fois. Le jeton d’API doit contenir au moins 32 caractères ASCII imprimables, sinon le serveur refuse de démarrer.

Les SDKs client, au nombre de huit, supportent les deux API ; aucune modification de code n’est requise tant que le proxy autorise la méthode HTTP QUERY. Les requêtes EventQL doivent être revues : les comparaisons de types, le traitement de l’ID comme chaîne et l’interprétation UTC des dates peuvent modifier les résultats.