williamandClaude Sonnet 5
5c069ae1fe
Reproduit à l'identique le cas signalé (objet "dialog" avec les champs
order/spiker/text/level_id/parcour_id) : le champ "order" est un mot
réservé SQL — "CREATE TABLE dialog (order INTEGER, ...)" plante avec
"OperationalError: near \"order\": syntax error". Comme ce crash survient
APRÈS l'INSERT de la ligne _definitions mais AVANT le commit(), rien
n'était jamais persisté : l'objet ENTIER disparaissait, malgré des champs
parfaitement remplis — d'où "j'ai tout rempli comme il faut et aucun objet
n'est créé". Mon précédent correctif (champ "Relation" sans cible) était
réel mais ne couvrait pas ce cas précis.
Cause de fond : chaque nom de colonne (dérivé du nom de champ tapé par
l'utilisateur, via slugify) était interpolé TEL QUEL dans du SQL brut
(CREATE TABLE, INSERT, UPDATE, ALTER TABLE ADD/DROP/RENAME COLUMN) sans
jamais être encadré de guillemets — n'importe quel nom de champ qui soit
aussi un mot réservé SQLite (order, group, index, select, where, table,
key, default, check, references, unique...) déclenchait exactement le
même crash-et-perte-de-transaction, dans n'importe laquelle de ces
opérations.
Correctif général (pas un simple contournement pour "order") :
db/quote_ident.py encadre tout identifiant de colonne de guillemets
doubles (forme standard SQL, supportée par SQLite) — appliqué partout où
un nom de colonne utilisateur est interpolé dans du SQL brut :
create_definition, add_field_to_definition, delete_field, update_field
(RENAME COLUMN), insert_row, update_row, update_row_field,
rows_referencing. Les noms de TABLE n'ont pas besoin de cette protection
(table_name_for.py les préfixe toujours "obj_", donc jamais un mot réservé
à eux seuls).
Trois nouveaux tests (tests/test_reserved_sql_keyword_field_names.py) :
création avec un champ "order" + insertion/lecture/mise à jour d'une
ligne, renommage d'un champ vers/depuis un mot réservé ("group"), ajout
d'un champ "select" à un objet existant — les trois confirmés en échec
sur l'ancien code (même erreur reproduite) puis au vert avec le
correctif. 136 tests au vert au total.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
16 lines
1008 B
Python
16 lines
1008 B
Python
def quote_ident(name):
|
|
"""Encadre un identifiant SQL (nom de colonne) de guillemets doubles —
|
|
forme standard SQL, supportée par SQLite, pour pouvoir utiliser un nom
|
|
de colonne qui serait sinon un mot réservé (ex. un champ appelé
|
|
"order" : sans ça, "CREATE TABLE ... (order INTEGER)" plantait avec
|
|
"OperationalError: near \"order\": syntax error", et comme le crash
|
|
survient APRÈS l'INSERT de la ligne _definitions mais AVANT le
|
|
commit(), rien n'était jamais persisté — l'objet entier disparaissait
|
|
silencieusement, pas seulement le champ en cause). Les noms de colonne
|
|
viennent tous de slugify() (utilisateur), jamais les noms de TABLE
|
|
(toujours préfixés "obj_" par table_name_for.py, donc jamais un mot
|
|
réservé à eux seuls) — seules les colonnes ont besoin de ça. Double les
|
|
guillemets internes (échappement standard SQL), au cas improbable où un
|
|
nom en contiendrait déjà un."""
|
|
return '"' + str(name).replace('"', '""') + '"'
|