Bémol. La limitation fondamentale de SQLite est son modèle de verrouillage rudimentaire, même comparé à MySQL. En effet, toute requête en écriture et même toute transaction ouverte sur la base verrouille toute la base de façon exclusive.
Bémol sur ton bémol : si tu lis un peu plus loin, tu verras qu'une solution est proposée pour pouvoir verouiller sur des tables : stocker une table par base (donc par fichier) et attacher les bases entre elles pour que le SGBD les voie comme une base unique :
A limited form of table-level locking is now also available in SQLite. If each table is stored in a separate database file, those separate files can be attached to the main database (using the ATTACH command) and the combined databases will function as one. But locks will only be acquired on individual files as needed. So if you redefine "database" to mean two or more database files, then it is entirely possible for two processes to be writing to the same database at the same time. To further support this capability, commits of transactions involving two or more ATTACHed database are now atomic.
c'est sûr, c'est quand même assez contraignant...
L'idéal serait, je pense, de pouvoir spécifier le mode de stockage des tables lors de la création de la base (dans un fichier unique pour toutes les tables, ou dans un répertoire unique avec des fichiers distincts par table). Et là on aurait à moindres frais un verouillage au niveau de la table...
Je vais envoyer un e-mail au mainteneur pour lui proposer l'idée.
[^] # Oui, mais... [workaround]
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 6.
Bémol sur ton bémol : si tu lis un peu plus loin, tu verras qu'une solution est proposée pour pouvoir verouiller sur des tables : stocker une table par base (donc par fichier) et attacher les bases entre elles pour que le SGBD les voie comme une base unique :
A limited form of table-level locking is now also available in SQLite. If each table is stored in a separate database file, those separate files can be attached to the main database (using the ATTACH command) and the combined databases will function as one. But locks will only be acquired on individual files as needed. So if you redefine "database" to mean two or more database files, then it is entirely possible for two processes to be writing to the same database at the same time. To further support this capability, commits of transactions involving two or more ATTACHed database are now atomic.
c'est sûr, c'est quand même assez contraignant...
L'idéal serait, je pense, de pouvoir spécifier le mode de stockage des tables lors de la création de la base (dans un fichier unique pour toutes les tables, ou dans un répertoire unique avec des fichiers distincts par table). Et là on aurait à moindres frais un verouillage au niveau de la table...
Je vais envoyer un e-mail au mainteneur pour lui proposer l'idée.