Ben voilà, peut-être une explication. Mais je ne suis pas sur que cela soit celle de bombe fourche.
Ma problématique est la suivante : imaginons que j'ai une table plop avec un champ creation_date.
Si le champ est de type timestamp, plop->all[0]->creation_date est un objet perl DateTime.
Si le champ est de type text ou autre (fonctionnement de sqlite), plop->all[0]->creation_date est de type text ou autre, et il faut modifier manuellement le schéma généré pour que ce soit automatiquement désérialisé dans un objet DateTime.
Sinon en ce qui concerne les ORM j'ai tendance à être d'accord avec toi, d'où le choix de DBIx : il est très léger et a pour principal intérêt de ne pas avoir à faire trainer dans le code une requête SQL suivie d'une boucle pour les select relativement simples.
[^] # Re: t'accuse
Posté par from_kobb . En réponse au journal MySQL est une bouse immonde. Évalué à 3.
Ma problématique est la suivante : imaginons que j'ai une table plop avec un champ creation_date.
Si le champ est de type timestamp, plop->all[0]->creation_date est un objet perl DateTime.
Si le champ est de type text ou autre (fonctionnement de sqlite), plop->all[0]->creation_date est de type text ou autre, et il faut modifier manuellement le schéma généré pour que ce soit automatiquement désérialisé dans un objet DateTime.
Sinon en ce qui concerne les ORM j'ai tendance à être d'accord avec toi, d'où le choix de DBIx : il est très léger et a pour principal intérêt de ne pas avoir à faire trainer dans le code une requête SQL suivie d'une boucle pour les select relativement simples.