Discussion :

[fatbob]

Bonjour,
En lisant la documentation symfony, j'ai trouvé que symfony tirait parti de certains éléments de la base de données dès lors qu'ils sont définis de manière correcte.
- id est le nom du champ utilisé en PK
- table_id celui des champs FK en provenance de la table "table"
- created_at et updated_at pour les timestamps de création et de modification.

N'ayant pas trouvé de liste exhaustive des particularités de définition des champs de la base dont symfony sait tirer parti, je ne suis pas sûr d'avoir tout relevé.

Une base bien définie me semblant être les fondations d'une application solide, j'aimerais modéliser la mienne de telle sorte qu'elle tire au mieux parti du framework.

Quelqu'un pourrait-il compléter ou valider cette liste (n'existe-t-il pas des champs created_by par exemple) ?

Est-il possible de définir des PK sur plusieurs champs avec des champs de FK sans perdre les fonctionnalités de symfony ?

Merci pour vos éclairages.

[Michel Rotta]

Pour les PK, j'ai traité dans ton autre messages, je vais donc passer ici.

En fait, la majorité des noms de ce type sont issues de doctrine avant d'être cannibalisé dans symfony. En faire un inventaire exhaustif demanderait plusieurs heures et un document important (si on veut les décrire précisément)

Tu as cité les principaux.

Mais il s'agit plus de convention de nommage que d'obligation, en effet, rien n'interdit (même si je pense que c'est une mauvaise idée sous symfony) d'appeler la PK 'monIdAMoi", de renommer le "created_at" en "creer_le" et ainsi de suite. Le code sera juste moins lisible par un autre développeur symfony.

Non, il n'existe pas de "updated_by" et c'est bien dommage, cela pourrait être un élément de "sfGuardDoctrinePlugins". Maintenant, c'est relativement simple à mettre en œuvre avec un minimum de surcharge dans le code.

"Une base bien définie me semblant être les fondations d'une application solide, j'aimerais modéliser la mienne de telle sorte qu'elle tire au mieux parti du framework." En fait, ce que tu souhaites n'est pas réalisable. Soit tu as une base bien définie, au sens de l'analyse et des formes normales, mais elle ne sera pas facilement utilisable dans symfony, soit tu as une base qui fonctionne bien avec symfony, mais du devras faire des concessions avec le modèle (MLD).

[fatbob]

En fait, la majorité des noms de ce type sont issues de doctrine avant d'être cannibalisé dans symfony. En faire un inventaire exhaustif demanderait plusieurs heures et un document important (si on veut les décrire précisément)

Peut-être dans la doc Doctrine, alors...

Tu as cité les principaux.

Mais il s'agit plus de convention de nommage que d'obligation, en effet, rien n'interdit (même si je pense que c'est une mauvaise idée sous symfony)

Plus où moins... D'après ce que j'ai compris, nommer un champ 'created_at' fera qu'il sera géré automatiquement par symfony (ou Doctrine, en fait). Ce n'est donc pas tout à fait équivalent.

"Une base bien définie me semblant être les fondations d'une application solide, j'aimerais modéliser la mienne de telle sorte qu'elle tire au mieux parti du framework." En fait, ce que tu souhaites n'est pas réalisable. Soit tu as une base bien définie, au sens de l'analyse et des formes normales, mais elle ne sera pas facilement utilisable dans symfony, soit tu as une base qui fonctionne bien avec symfony, mais du devras faire des concessions avec le modèle (MLD).

Des compromis, toujours des compromis . Et moi qui pensais que Symfony...
Avant de choisir l'option, il faudra donc que je teste davantage...

Merci, en tout cas, pour cette réponse claire.

[Michel Rotta]

Pour created_at, c'était vrai avec propel (le fait qu'il soit automatiquement reconnu et traité). Avec Doctrine, il faut mettre en place, dans la base un behavior "timestampable" qui le prend en charge, et permet de modifier le nom.


Il n'y a pas de framework parfait, ou il est trop permissif, du genre du send, quoique, les nouvelles versions semblerait l'être moins. Soit il est plus contraignants, ce que je trouve une bonne chose, mais il faut alors accepter les contraintes, après tous, il reste la possibilité de tous faire à la main. Mais je ne pense pas que cela soit la meilleur solution.