SQLite et champs 'maj' (timestamp)
Nous avons vu hier avec Eric que les champs de type 'maj' (current timestamp en mysql) se comportent différemment sous sqlite avec certaines fonctions : sql_insert
et sql_query
particulièrement.
En mysql le champ est rempli dès l’insertion d’une entrée dans la table.
En sqlite, à l’insertion, null
est inséré.
Sur un update, le champ est par contre correctement redéfini avec un timestamp.
Ça se passe en fait pour SQLite dans https://git.spip.net/spip/spip/src/branch/master/ecrire/req/sqlite_generique.php : le champ maj est mis à jour en utilisant la fonction _sqlite_ajouter_champs_timestamp()
qui est appelée à différents moments, mais pas sur spip_sqlite_insert()
ni spip_sqlite_query()
Effectivement dans ces 2 cas ce serait difficile à analyser.
Ce n’est pas forcément gênant :
- on sait déjà qu’il faut préférer les autres fonctions
sql_*q()
- ce n’est pas la fin du monde d’avoir null à l’insertion pour un champ
maj
- ce champ ne devrait pas servir de référence non plus pour des critères de date car il peut se mettre à jour pour tout un tas de raisons (ie: une modification sur la ligne sql, mais qui ne concerne en rien un contenu éditorial)
Ceci étant dit ça reste un comportement différent d’avec mysql.
En SQLite la solution propre pour gérer cela était avec des triggers, mais tout de suite c’est pas le même topo. Mais je vois aussi qu’il semblerait exister DEFAULT CURRENT_TIMESTAMP
. On pourrait peut être basculer les champs sur des TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP