Log:
Permettre à SQLite de faire des requetes qu'il ne connait pas : ALTER TABLE table (DROP|CHANGE|MODIFY) column
Pour cela, la seule solution est :
A) découpage de la requete en autant de sous requete s'il y a (cas des referers qui ont 3 modifications DROP, CHANGE, ADD dans une seule requete), puis
B) executer la sous-requete, sauf pour des sous requetes DROP, CHANGE ou MODIFY :
1) créer une table temporaire avec le contenu table à modifier (long sur les grosses bases ?),
2) supprimer la table à modifier,
3) recréer la table en tenant compte des changements
4) copier les contenus qui correspondent de la table teporaire à la table recrée (long?)
5) supprimer la table temporaire
Du coup, au vu du risque sur ces requetes pour les grosses bases lors d'une mise à jour de SPIP, je ne saurais que trop conseiller de ne pas oublier de faire un DUMP avant ! (Il est fréquent que les mises à jour de SPIP utilisent ALTER TABLE ... DROP|CHANGE|MODIFY ...
1) créer une table temporaire avec le contenu table à modifier (long sur les grosses bases ?),
2) supprimer la table à modifier,
3) recréer la table en tenant compte des changements
Log:
Permettre à SQLite de faire des requetes qu'il ne connait pas : ALTER
TABLE table (DROP|CHANGE|MODIFY) column
....
Du coup, au vu du risque sur ces requetes pour les grosses bases lors
d'une mise à jour de SPIP, je ne saurais que trop conseiller de ne pas
oublier de faire un DUMP avant ! (Il est fréquent que les mises à jour de
SPIP utilisent ALTER TABLE ... DROP|CHANGE|MODIFY ...
Dans ce cas est-ce qu'il ne serait pas possible d'encapsuler ce traitement
dans une transaction (me semble que sqllite les gère) ?
A+
Dans ce cas est-ce qu'il ne serait pas possible d'encapsuler ce traitement dans une transaction (me semble que sqllite les gère) ?
A+
Oui, Renato venait de me souffler l'idée (en fait, je ne pensais pas que l'on pouvait mettre dans une requete un "BEGIN TRANSCTION...").
Je suis en train de tester justement.
