Posté par laurentm .
En réponse à la dépêche Retour sur Django 1.5.
Évalué à 4.
Dernière modification le 07 mai 2013 à 10:16.
il ne gère pas des transactions "tout en un" comme le fait SQLAlchemy par exemple
Si je comprends bien de quoi tu parles, c'est tout à fait possible avec Django, mais ce n'est pas le comportement par défaut (ce que je trouve dommage…).
Par défaut, Django fait de l'auto-commit pour chaque query, c'est pas terrible dans certain cas (comme celui de ton exemple). Mais il est toutefois est possible de coupler une transaction SQL à une requête HTTP. Dans ce cas, la transaction commence avant le traitement de la View et est commitée si tout se passe bien, si une exception est levée pendant le traitement, la transaction est annulée (rollback).
Django permet également de gérer finement les transactions en indiquant explicitement quand elle commence, et si on fait un commit ou un rollback.
Pour les cas tordus comme une transaction qui dure plusieurs requêtes HTTP (dans le cas d'un wizard qui est sur plusieurs "écrans" par exemple), je ne sais pas si c'est possible avec Django, je n'en ai jamais eu besoin.
Pour les autres points, je suis d'accord avec toi.
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par laurentm . En réponse à la dépêche Retour sur Django 1.5. Évalué à 4. Dernière modification le 07 mai 2013 à 10:16.
Si je comprends bien de quoi tu parles, c'est tout à fait possible avec Django, mais ce n'est pas le comportement par défaut (ce que je trouve dommage…).
Par défaut, Django fait de l'auto-commit pour chaque query, c'est pas terrible dans certain cas (comme celui de ton exemple). Mais il est toutefois est possible de coupler une transaction SQL à une requête HTTP. Dans ce cas, la transaction commence avant le traitement de la View et est commitée si tout se passe bien, si une exception est levée pendant le traitement, la transaction est annulée (rollback).
Django permet également de gérer finement les transactions en indiquant explicitement quand elle commence, et si on fait un commit ou un rollback.
Tous les détails sont ici : https://docs.djangoproject.com/en/1.5/topics/db/transactions/
Pour les cas tordus comme une transaction qui dure plusieurs requêtes HTTP (dans le cas d'un wizard qui est sur plusieurs "écrans" par exemple), je ne sais pas si c'est possible avec Django, je n'en ai jamais eu besoin.
Pour les autres points, je suis d'accord avec toi.