Propel n'est pas vraiment un ORM. Enfin, pas au sens où je vois l'ORM. Mais il s'en approche c'est sûr.

Tu peux développer ça stp ? Quelles sont les lacunes de propel qui te font dire ce blasphème ?

Hihi.
D'après moi et ma conception de l'ORM, Propel n'en est pas pas réellement un. Les grandes lignes (schéma → modèle → requêtage) sont bonnes, mais c'est la façon de procéder que je n'aime pas. Je n'aime pas le modèle, je n'aime pas la façon dont on doit faire les requêtes. Dans quasiment tous les cas, on doit écrire plus de code que si on avait utilisé un bête mysql_query, huh ?!

Je n'ai pas étudié en profondeur l'utilisation de Propel. Je me suis basé sur des dires, des exemples, et mon observation. Comme on bosse sur notre propre ORM, je regarde comment procèdent les autres à différent niveau, et Propel — même s'il est le meilleur actuellement[1] — ne correspond pas à ma définition de l'ORM .
C'est par rapport à moi, dites moi si je me trompe.


[1] actuellement ne sous-entend pas qu'on va réussir à faire mieux et virer Propel du marché, c'est plus une façon de parler.

[...]L'image que Tracker a de l'ORM quand il parle de mise en mémoire par exemple, c'est un ORM type Java : EJB par exemple. Mais on ne peut pas faire ça en PHP, ce serait beaucoup trop lourd.
Sékil avait dit une chose pas bête du tout une fois (je ne retrouve plus le sujet), c'est que PHP rencontre du succès car il répond aux exigences du Web, à savoir : il fait les choses bien et vite. Une application écrite en Objective C ou Java est appelée à être exécutée 1 seule fois en même temps (sauf cas particulier). Une application écrite en PHP est appelée à être exécutée des 10 000 fois à la minute, voire 10 fois plus pour de grosses applications. On ne peut pas déployer un système comme les EJB en PHP, c'est du suicide et de la folie furieuse (et un non-sens effrayant …).[...]

C'est pas la partie EJB, mais JPA qu'il serait intéressant de récupérer, en php la difficulté est qu'il n'y a pas de mémoire accessible par tous les threads, c-à-d que si x thread requièrent le même objet, on va abortir à la création de x instance de la même entité, et non une seule dont l'exclusivité pourrait-être donnée à un client particulier. Le problème d'exclusivité est donc obligatoirement délégué à la base afin de garantir l'intégrité des traitements, chose qui n'est pas faite avec Propel (cf post précédent).


Tracker.

Hihi.
D'après moi et ma conception de l'ORM, Propel n'en est pas pas réellement un. Les grandes lignes (schéma → modèle → requêtage) sont bonnes, mais c'est la façon de procéder que je n'aime pas. Je n'aime pas le modèle, je n'aime pas la façon dont on doit faire les requêtes. Dans quasiment tous les cas, on doit écrire plus de code que si on avait utilisé un bête mysql_query, huh ?!

En fait, pour résumer, propel ne te plaît tout simplement pas (ce que je comprends très bien, si tu avais pu entendre le nombre d'insultes que j'ai pu dire envers Criteria... Je trouve moi-même cette classe à la fois limitante, peu naturelle et éloignée des avantages du langage SQL. ). Je pense qu'il faut avoir travaillé un moment avec pour se faire une véritable idée, le premier contact est _presque forcément_ négatif.

Sur le modèle, sans être parfaites, les classes propel permet quand même pas mal de choses et ont à mon sens plus d'avantages que d'inconvénients.

Mais sur l'essentiel, Propel crée véritablement une analogie entre un enregistrement en BDD et un objet dans ton code. Il ne le fait peut-être pas à ton goût, mais il est faux de dire que ce n'est pas un ORM

Merci pour cette réponse plus que complète. \o/

@Calimero : Oui j'ai du mal m'exprimer. Propel est une sorte d'ORM, juste qu'il est un peu éloigné de ma conception de l'ORM « parfait », mais tu as raison .