Ce que tu indiques dans ton billet, as été pris en compte. Il s'avère que PMO récupère un desc des tables sur lesquels il travaille, qu'il insère dans des objets PMO_MyTable.
Cette intérrogation en terme de ressource est inexistante étant donné que le SGBD implicitement cache ses informations pour pouvoir travailler sur les données. Le SGBD ne fait que te renvoyer que ce qu'il a en cache: ça coute pinuts par rapport à un simple SELECT.
Si tu compares ce mécanisme à un mécanisme persistant de déclaration XML comme c'est le cas pour la plus part des autres ORM. C'est beaucoup plus lent, et couteux en terme de ressources d'ouvrir un fichier, de parser du xml, que d'intérroger le cache du SGBD ;) Sans compter les problèmes de mise à jour etc ...
Cacher les objets, ça sera peut être à l'étude dans les prochaines versions.
[^] # Re: argh !
Posté par Code34 . En réponse au journal PMO version 0.09. Évalué à 1.
Cette intérrogation en terme de ressource est inexistante étant donné que le SGBD implicitement cache ses informations pour pouvoir travailler sur les données. Le SGBD ne fait que te renvoyer que ce qu'il a en cache: ça coute pinuts par rapport à un simple SELECT.
Si tu compares ce mécanisme à un mécanisme persistant de déclaration XML comme c'est le cas pour la plus part des autres ORM. C'est beaucoup plus lent, et couteux en terme de ressources d'ouvrir un fichier, de parser du xml, que d'intérroger le cache du SGBD ;) Sans compter les problèmes de mise à jour etc ...
Cacher les objets, ça sera peut être à l'étude dans les prochaines versions.