On utilise une surcouche maison (sheraf) sur ZODB qui fait un peu l'équivalent d'un ORM. Ajouter un attribut sur un objet se fait sans migration, en supprimer un pareil (mais dans ce cas les données restent en base jusqu'à la prochaine écriture de l'objet). Renommer un attribut peut aussi se faire sans migration en ajoutant un paramètre (mais une migration pour renommer l'attribut est évidemment possible). Évidemment, des migrations restent nécessaires si on veut découper un objet en deux, etc. Dans ce cas, il faut écrire un script Python, ce qui permet d'avoir accès à l'ensemble des attributs, méthodes sur les objets à transformer.
Je suis tout à fait d'accord sur la qualité des migrations SQL. Par contre, on a l'impression de perdre du temps à les faire. Notre pire cas d'usage est avec Django: certaines migrations sont inutiles car elles touchent des paramètres inutilisés en base, les migrations ne permettent pas l'utilisation des méthodes attachées aux objets. C'est plus lié à Django lui-même qu'à PostgreSQL, mais c'est une mauvaise expérience. On a aussi des cas avec Flask/SQLAlchemy qui sont plus agréables, sans soulever l'enthousiasme.
Peut-être que la conclusion sera que PostgreSQL reste le meilleur choix. Pour l'instant, on explore les pistes.
[^] # Re: PostgreSQL partout
Posté par srb (site web personnel) . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 3.
On utilise une surcouche maison (sheraf) sur ZODB qui fait un peu l'équivalent d'un ORM. Ajouter un attribut sur un objet se fait sans migration, en supprimer un pareil (mais dans ce cas les données restent en base jusqu'à la prochaine écriture de l'objet). Renommer un attribut peut aussi se faire sans migration en ajoutant un paramètre (mais une migration pour renommer l'attribut est évidemment possible). Évidemment, des migrations restent nécessaires si on veut découper un objet en deux, etc. Dans ce cas, il faut écrire un script Python, ce qui permet d'avoir accès à l'ensemble des attributs, méthodes sur les objets à transformer.
Je suis tout à fait d'accord sur la qualité des migrations SQL. Par contre, on a l'impression de perdre du temps à les faire. Notre pire cas d'usage est avec Django: certaines migrations sont inutiles car elles touchent des paramètres inutilisés en base, les migrations ne permettent pas l'utilisation des méthodes attachées aux objets. C'est plus lié à Django lui-même qu'à PostgreSQL, mais c'est une mauvaise expérience. On a aussi des cas avec Flask/SQLAlchemy qui sont plus agréables, sans soulever l'enthousiasme.
Peut-être que la conclusion sera que PostgreSQL reste le meilleur choix. Pour l'instant, on explore les pistes.