- Expédié
- 11 août 2026 à 18:36 UTC
- Auteur
- Kamo
- Commite
- b4fd867
Trouvé en le faisant fonctionner. YugabyteDB effectue un changement de schéma en ligne, donc un INDICE UNIQUE CREATE publié alors que la passe ddl-auto d'Hibernate est encore en train de s'installer peut perdre la course et revenir 40001 "ne pourrait pas sérialiser l'accès en raison d'une mise à jour simultanée". La mention est fine - la déclaration identique on réussit quelques instants plus tard. Traiter cela comme mortel était bien pire qu'il n'y paraît. Ce coureur est l'ordonnance(43), donc le lancer avorté de l'initialiseur entier et a sauté les 27 coureurs commandés après lui. Un conflit transitoire donc silencieusement refusé chaque migration ultérieure sur la plate-forme, et le seul symptôme visible était une trace de pile au milieu d'une course par ailleurs normale. AssurerRequired et ensureCheckConstraint réessai jusqu'à cinq fois avec un backoff linéaire lorsque l'échec est un conflit simultané, apparié sur SQLSTATE 40001 et sur le message (le conducteur le surface dans les deux sens en fonction de l'endroit où il est soulevé) et de marcher sur la chaîne de cause, parce que Spring Il l'enveloppe. L'allumette est délibérément étroite: une table manquante, une mauvaise colonne ou une double clé Un conflit sur les données réelles est un défaut qui doit encore échouer fort plutôt que d'être rejugé quatre autres et ensuite échouer de toute façon. Vérifié par rapport à la base de données en direct après le correctif: les 20 tables de formation sont présentes, les cinq création d'indices uniques requis, le cours en deux colonnes en place, les quatre courriels de formation des gabarits ensemencés (une rangée SYSTEM plus 13 lignes d'org chacun), et chaque coureur après l'ordre (43) atteint.