De ce que j'ai lu à propos de l'ORM de Django, et par rapport à SQLAlchemy que je connais bien :
- il ne supporte les clés primaires multiples que depuis la version 1.5 (la dernière). Pour quelqu'un qui conçoit un schéma de base avec en tête l'idée que la base de données garantit autant que faire se peut l'intégrité et la cohérence des données, c'est un cas classique.
- il ne gère pas des transactions "tout en un" comme le fait SQLAlchemy par exemple. Exemple : tu as un formulaire qui génère différentes requêtes SQL qui doivent êtres toutes faites dans une unique transaction, Django ne le gère pas. Dans beaucoup de cas, ce n'est pas utile, mais dans certains cas c'est rédhibitoire. Par exemple, si ton formulaire doit faire un insert dans 2 tables et que l'un ne va pas sans l'autre, ce n'est pas garanti quand tu développes avec Django, ça l'est (ou ça peut l'être) quand tu utilises SQLAlchemy
- tu ne peux pas utiliser l'ORM de Django sans emporter avec toi django-full-package ;)
- il n'enregistre pas "les valeurs qui ont été changées" mais "un tuple complet" ; quoique visiblement cela ait été amélioré dans la dernière version.
En fait, pour moi ce qui est vraiment "moche", c'est d'emporter tout Django si tu veux juste l'ORM. Par exemple, si j'ai un client lourd et une appli web qui accèdent à la même base de données, soit je dois utiliser 2 technos différentes pour faire l'ORM, soit je dois embarquer Django dans mon client lourt.
Est-ce que tu utiliserais une techno qui t'impose d'embarquer QT pour tes applis web ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Retour sur Django 1.5. Évalué à 1.
De ce que j'ai lu à propos de l'ORM de Django, et par rapport à SQLAlchemy que je connais bien :
- il ne supporte les clés primaires multiples que depuis la version 1.5 (la dernière). Pour quelqu'un qui conçoit un schéma de base avec en tête l'idée que la base de données garantit autant que faire se peut l'intégrité et la cohérence des données, c'est un cas classique.
- il ne gère pas des transactions "tout en un" comme le fait SQLAlchemy par exemple. Exemple : tu as un formulaire qui génère différentes requêtes SQL qui doivent êtres toutes faites dans une unique transaction, Django ne le gère pas. Dans beaucoup de cas, ce n'est pas utile, mais dans certains cas c'est rédhibitoire. Par exemple, si ton formulaire doit faire un insert dans 2 tables et que l'un ne va pas sans l'autre, ce n'est pas garanti quand tu développes avec Django, ça l'est (ou ça peut l'être) quand tu utilises SQLAlchemy
- tu ne peux pas utiliser l'ORM de Django sans emporter avec toi django-full-package ;)
- il n'enregistre pas "les valeurs qui ont été changées" mais "un tuple complet" ; quoique visiblement cela ait été amélioré dans la dernière version.
En fait, pour moi ce qui est vraiment "moche", c'est d'emporter tout Django si tu veux juste l'ORM. Par exemple, si j'ai un client lourd et une appli web qui accèdent à la même base de données, soit je dois utiliser 2 technos différentes pour faire l'ORM, soit je dois embarquer Django dans mon client lourt.
Est-ce que tu utiliserais une techno qui t'impose d'embarquer QT pour tes applis web ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo