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>
30 lines
1.1 KiB
Python
30 lines
1.1 KiB
Python
import sqlite3
|
|
|
|
from ..connection import connect
|
|
from ..quote_ident import quote_ident
|
|
from ..slugify import slugify
|
|
from .get_definition import get_definition
|
|
|
|
|
|
def delete_field(slug, definition_id, field_id):
|
|
"""CRUD — Update d'une définition : retire un champ. Exécute un vrai
|
|
ALTER TABLE ... DROP COLUMN (SQLite ≥ 3.35). Sur une version de SQLite
|
|
trop ancienne pour DROP COLUMN, le champ est retiré de la définition
|
|
(le moteur ne le proposera plus dans les formulaires) mais la colonne
|
|
SQL peut subsister sans casser quoi que ce soit d'autre."""
|
|
definition = get_definition(slug, definition_id)
|
|
field = next((f for f in definition["fields"] if f["id"] == field_id), None)
|
|
if not field:
|
|
return
|
|
col = slugify(field["name"]).replace("-", "_")
|
|
if field["type"] == "relation":
|
|
col += "_id"
|
|
conn = connect(slug)
|
|
try:
|
|
conn.execute(f"ALTER TABLE {definition['table_name']} DROP COLUMN {quote_ident(col)}")
|
|
except sqlite3.OperationalError:
|
|
pass
|
|
conn.execute("DELETE FROM _fields WHERE id = ?", (field_id,))
|
|
conn.commit()
|
|
conn.close()
|