Sauf que par exemple ça ne gère pas les fractions de seconde ni les fuseaux horaires.
Avec une bonne couche d'abstraction, si j'ai un datetime avec un fuseau horaire et des microsecondes et que je le sauve dans une base PostgreSQL, je ne perds pas d'information.
Ça c'est un manquement dans la PEP. Bien que perso, je pense qu'il est préférable de stocker tout en UTC.
De plus, tous les SGDB ne supportent pas les fuseaux horaires par example SQLite.
Ben oui, mais qui écrit / invoque l'adaptateur ? Si c'est ta bibliothèque, alors elle n'ignore plus le type de BD utilisé :-) Si c'est l'utilisateur, ta bibliothèque est sous-optimale par rapport à d'autres solutions.
Je ne trouve pas que ce soit le rôle de la librairie de faire ces choix.
Par exemple, pour Tryton, on a des adaptateurs spécifiques pour les float et Decimal sous PostgreSQL.
[^] # Re: SQLalchemy
Posté par Cédric Krier (site web personnel, Mastodon) . En réponse au journal python-sql n'est pas un ORM. Évalué à 3.
Ça c'est un manquement dans la PEP. Bien que perso, je pense qu'il est préférable de stocker tout en UTC.
De plus, tous les SGDB ne supportent pas les fuseaux horaires par example SQLite.
Je ne trouve pas que ce soit le rôle de la librairie de faire ces choix.
Par exemple, pour Tryton, on a des adaptateurs spécifiques pour les
floatetDecimalsous PostgreSQL.