Update chapters
Updated chapters 2, 6, 8, 9 and 11.
This commit is contained in:
@ -46,7 +46,7 @@ Cette table ne possède pas de contrainte particulière et autorise à enregistr
|
||||
```python {.numberLines}
|
||||
import sqlite3
|
||||
|
||||
connection = sqlite3.connect("intro.sqlite3", isolation_level=None)
|
||||
connection = sqlite3.connect("intro.sqlite3", autocommit=True)
|
||||
cursor = connection.cursor() # cet objet est utilisé pour envoyer des requêtes
|
||||
cursor.execute("""
|
||||
CREATE TABLE IF NOT EXISTS person (
|
||||
@ -126,7 +126,7 @@ Les objets de type `sqlite3.Row`{.python} sont utilisables comme des dictionnair
|
||||
|
||||
----
|
||||
|
||||
## Hors-programme : Requêtes universelles avec les ORMs
|
||||
## Hors-programme : Les [ORM]{.naming}
|
||||
|
||||
C'est bien d'envoyer du SQL à une base de données, mais le problème du standard SQL, c'est que
|
||||
tous les systèmes de gestion de bases de données ne gèrent pas toujours le SQL de la même façon;
|
||||
@ -138,7 +138,7 @@ très probablement de retoucher ou d'adapter vos requêtes.
|
||||
|
||||
----
|
||||
|
||||
Ce problème est, entre autres questionnements, à l'origine de l'existence des ORMs (`Object Relational Mapper`).
|
||||
Ce problème est, entre autres questionnements, à l'origine de l'existence des ORMs ([Object Relational Mapper]{.naming}).
|
||||
Ce sont des bibliothèques qui offrent une abstraction de la base de données et la remplacent par
|
||||
l'écriture de code, non plus en SQL, mais dans votre langage **orienté objet** préféré,
|
||||
pour représenter des schémas et manipuler vos données.
|
||||
@ -167,43 +167,6 @@ en charge par l'ORM).
|
||||
|
||||
----
|
||||
|
||||
## Bonus : Petite explication sur `isolation_level`
|
||||
|
||||
Dans notre premier slide contenant du code, nous avons défini un argument facultatif à la fonction `connect`, nommé
|
||||
`isolation_level`. Celui-ci permet de définir le [niveau d'isolation](https://en.wikipedia.org/wiki/Isolation_(database_systems)) des commandes SQL que l'on envoie.
|
||||
|
||||
Si l'on passe la valeur `None`{.python} à cet argument, l'auto-commit est activé, ce qui signifie que nous n'avons plus besoin
|
||||
d'appeler manuellement `commit()`{.python} lorsqu'on souhaite persister nos modifications. Ceci est normalement le comportement
|
||||
par défaut pour toute bibliothèque DBAPI, mais pour une raison inconnue, cela n'est pas le cas pour `sqlite`. Le bug sera corrigé
|
||||
dans Python 3.12.
|
||||
|
||||
----
|
||||
|
||||
En temps normal, si nous n'avions pas précisé ce paramètre :
|
||||
|
||||
- Ouvrir la connexion (sans autocommit)
|
||||
- `connection.execute()`{.python} → ouvre une transaction
|
||||
- `connection.execute()`{.python}
|
||||
- `connection.execute()`{.python}
|
||||
- Aucune modification n'est persistée tant qu'on n'appelle pas `connection.commit()`{.python}
|
||||
|
||||
Le fait de devoir `cnx.commit()`{.python} par défaut n'est pas spécialement intuitif, notamment
|
||||
lorsqu'on débute en bases de données...
|
||||
|
||||
----
|
||||
|
||||
Grâce à notre paramètre `isolation_level`, le comportement est plus intuitif par défaut :
|
||||
|
||||
- Ouvrir la connexion (avec autocommit)
|
||||
- `connection.execute()`{.python} → modification immédiate
|
||||
- `connection.execute()`{.python} → modification immédiate
|
||||
- `connection.execute("BEGIN")`{.python} → Ouverture explicite d'une transaction
|
||||
- `connection.execute()`{.python} → modification non persistée
|
||||
- `connection.execute("COMMIT")`{.python} → ferme la transaction et applique les modifications si
|
||||
possible
|
||||
|
||||
----
|
||||
|
||||
## Bibliothèques Python compatibles DB API 2.0 :
|
||||
|
||||
- MySQL : `pip install mysql-connector-python`{.shell} ([doc](https://dev.mysql.com/doc/connector-python/en/))
|
||||
|
Reference in New Issue
Block a user