Une manière d'améliorer la situation est de marquer les informations nouvelles (une
technique appelée dirty bit en anglais) et de n'écrire que ces parties modifiées en
base de données, de manière groupée. Par exemple, au lieu d'envoyer une requête
pour chaque nouveau genre ou livre inséré, le rôle dirty (à créer) des éléments
modifiés prend une valeur booléenne fausse. À un certain moment (par exemple,
lorsque l'utilisateur ferme la fenêtre d'édition des genres), toutes ces modifications
sont envoyées d'un coup au serveur, dans une seule requête SQL (ou encore après,
en même temps qu'une série de livres). Il faut cependant faire attention à bien
ajouter les nouveaux genres avant les nouveaux livres, ces derniers pouvant faire
référence aux premiers.
Quid des mises à jour du schéma ?
Le module LocalStorage n'est, actuellement, pas prévu pour gérer les mises à jour
du schéma de la base de données (en d'autres termes, la structure des tables),
contrairement à l'API HTML5 dont il s'inspire librement : à l'ouverture d'une
connexion avec la base de données, la fonction
LocalStorage.openDatabaseSync permet de spécifier un numéro de version et
renvoie une erreur si le numéro demandé ne correspond pas à celui de la base de
données. Cependant, les codes d'erreur ne sont pas documentés, c'est-à-dire qu'ils
pourraient changer d'une version à l'autre du module sans notification.
Pour passer outre cette limitation, la seule solution est de gérer soi-même les
numéros de version à l'intérieur de la base de données, en créant une table dont le
seul enregistrement contiendra la version actuelle de la base de données complète
(ou un numéro par table). Ainsi, lorsque la fonction openDatabaseSync renvoie
une instance de la base, avant toute autre opération, l'idée est de vérifier les
numéros de version : s'ils ne correspondent pas, il faut faire une mise à jour du
schéma de la base de données pour qu'il corresponde à celui attendu par la nouvelle
version de l'application.
La manière la plus courante d'écrire le code qui implémente ces mises à jour est de
le faire incrémentalement : si une table est en version 1.0, mais si la version
attendue par l'application est la 1.3, alors le code effectuera la mise à jour de la
1.0 vers la 1.1, puis la 1.2 et enfin la 1.3. Ainsi, vous ne devrez écrire que des
scripts de mise à jour assez simples et en nombre réduit. Les numéros de version du
schéma de la base de données ne doivent pas forcément correspondre à ceux de
l'application.
368
technique appelée dirty bit en anglais) et de n'écrire que ces parties modifiées en
base de données, de manière groupée. Par exemple, au lieu d'envoyer une requête
pour chaque nouveau genre ou livre inséré, le rôle dirty (à créer) des éléments
modifiés prend une valeur booléenne fausse. À un certain moment (par exemple,
lorsque l'utilisateur ferme la fenêtre d'édition des genres), toutes ces modifications
sont envoyées d'un coup au serveur, dans une seule requête SQL (ou encore après,
en même temps qu'une série de livres). Il faut cependant faire attention à bien
ajouter les nouveaux genres avant les nouveaux livres, ces derniers pouvant faire
référence aux premiers.
Quid des mises à jour du schéma ?
Le module LocalStorage n'est, actuellement, pas prévu pour gérer les mises à jour
du schéma de la base de données (en d'autres termes, la structure des tables),
contrairement à l'API HTML5 dont il s'inspire librement : à l'ouverture d'une
connexion avec la base de données, la fonction
LocalStorage.openDatabaseSync permet de spécifier un numéro de version et
renvoie une erreur si le numéro demandé ne correspond pas à celui de la base de
données. Cependant, les codes d'erreur ne sont pas documentés, c'est-à-dire qu'ils
pourraient changer d'une version à l'autre du module sans notification.
Pour passer outre cette limitation, la seule solution est de gérer soi-même les
numéros de version à l'intérieur de la base de données, en créant une table dont le
seul enregistrement contiendra la version actuelle de la base de données complète
(ou un numéro par table). Ainsi, lorsque la fonction openDatabaseSync renvoie
une instance de la base, avant toute autre opération, l'idée est de vérifier les
numéros de version : s'ils ne correspondent pas, il faut faire une mise à jour du
schéma de la base de données pour qu'il corresponde à celui attendu par la nouvelle
version de l'application.
La manière la plus courante d'écrire le code qui implémente ces mises à jour est de
le faire incrémentalement : si une table est en version 1.0, mais si la version
attendue par l'application est la 1.3, alors le code effectuera la mise à jour de la
1.0 vers la 1.1, puis la 1.2 et enfin la 1.3. Ainsi, vous ne devrez écrire que des
scripts de mise à jour assez simples et en nombre réduit. Les numéros de version du
schéma de la base de données ne doivent pas forcément correspondre à ceux de
l'application.
368