left join non prévu dans le schema

bonjour,

j'ai 2 tables, la premiere me permet de grouper à la création un groupe de personnes la seconde de gerer par personne des données par date:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

GrpeChqDejList: connection: doctrine tableName: GrpeChqDejList columns: grpechqdej_id: type: integer user_id: type: integer unique: true indexes: Unique: fields: [grpechqdej_id, user_id] type: unique relations: User: class: sfGuardUser local: user_id foreign: id GrpeChqDej: class: GrpeChqDej local: grpechqdej_id foreign: id   ChqDej: connection: doctrine tableName: cheqdej columns: user_id: type: integer date: type: timestamp conges: type: integer maladie: type: integer professionel: type: integer nbChq: type: integer indexes: Unique1: fields: [user_id, date] type: unique relations: User: class: sfGuardUser local: user_id foreign: id onDelete: CASCADE onUpdate: CASCADE

---

je ne désire pas avoir une relation forte entre ces deux tables mais j'ai besoin davoir un affichage par groupe donc en SQL ça donne:

Code:

---

1 2 3 4 5

SELECT G.`user_id`, MAX(c.date ) FROM GrpeChqDejList G LEFT OUTER JOIN cheqdej c ON c.user_id=G.user_id WHERE G.`grpechqdej_id`=1 GROUP BY G.`user_id`

---

que j'ai transcrit en doctrine:

Code:

---

1 2 3 4 5 6

$q = Doctrine_Query::create() ->select('a.user_id,MAX(c.date)') ->from('GrpeChqDejList a') ->leftJoin('cheqdej c ON a.user_id = c.userid') ->where('a.grpechqdej_id = ?',$id) ->execute();

---

malheureusement j'ai le message d'erreur:

Code:

---

Couldn't find class cheqdej

---

quelle est la bonne syntaxe ?

Tu n'as effectivement pas de classe : cheqdej
Mais une classe : ChqDej.

De manière plus générale, je te conseillerais d'être beaucoup plus vigilant dans tes nommages de classe, table, paramètres, etc.

D'une part, la lecture d'un nom doit être le plus explicite possible. En n'utilisant que des abréviations, j'ai dû prendre le temps de décoder tes noms pour comprendre ce qu'ils représentaient (ce qui est une mauvaise chose).

D'autre part, tu es constamment obligé de venir vérifier la bonne orthographe pour être sûr, lorsque tu utilises un nom autre part dans ton code, de ne pas te tromper dans la manière de l'écrire.

Certes, écrire "ChequeDejeuner" est plus long. Mais :
1. tu comprends beaucoup plus rapidement de quoi il s'agit ;
2. tu évites de te tromper entre cheqdej et ChqDej !

Après, peut-être as-tu aussi une erreur sur la manière dont est écrite la requête elle-même. Mais j'ai toujours du mal à écrire moi-même mes left join :)

effectivement c'était ça.
je n'avait pas compris qu'il faut mettre la classe et non la table dans le leftJoin :(

pour le nommage, vais essayer de faire des effort
merci

Si le shéma est correctement conçu (je n'ai pas vérifié le tiens) dans le leftjoin de doctrine tu ne mets ni le nom de la classe ni le nom de la table mais le nom de la relation (ou le nom défini par foreignAlias qui est le nom de la relation vu de l'autre côté de la relation.

j'ai pas de relation entre ces 2 tables dans mon schema, pour des raisons pratiques.

Bon par contre en faites ça ne marche toujours pas, si je n'ai pas de message d'erreur il ne me prend pas en compte ma liaison:
mon schéma doctrine:

Code:

---

1 2 3 4 5 6 7

$q = Doctrine_Query::create() ->select('a.user_id, DATE(MAX(c.date)) AS maxdate') ->from('GrpeChqDejList a') ->leftJoin('ChqDej c ON a.user_id = c.userid') ->groupBy('a.user_id') ->where('a.grpechqdej_id = ?',$id) ->execute();

---

et la requête SQL qui est généré:

Code:

---

SELECT g.id AS g__id, g.user_id AS g__user_id, DATE(MAX(c.date)) AS c__0 FROM GrpeChqDejList g, cheqdej c WHERE (g.grpechqdej_id = ?) GROUP BY g.user_id - (1)

---

EDIT: j'ai comme un doute, il y a moyen de faire un leftJoin qui n'est pas prévu dans le schéma ??

bon apres une demi journée a fouiné sur internet:
un leftjoin non prévu dans le schema ne fonctionne que si l'on a expressément indiqué les clés primaire de chacune des tables dans le select, c'est d'une logique...
donc voici le résultat:

Code:

---

1 2 3 4 5 6

$q = $this->createQuery('a') ->select('a.id,c.id, a.user_id, DATE(MAX(c.date)) AS maxdate') ->leftJoin('a.ChqDej c ON a.user_id = c.user_id') ->groupBy('a.user_id') ->where('a.grpechqdej_id = ?',$id) ->execute();

---

Citation:

---

Envoyé par erictomcat

j'ai pas de relation entre ces 2 tables dans mon schema, pour des raisons pratiques.

---

:koi:
Il me semble que cela soit justement moins pratique que de mettre simplement les relations.

La méthode doctrine lsftJoint() est conçue pour fonctionner avec des relations déclarées dans le schéma, forcément, si tu ne veux pas les utiliser, elle va fonctionner beaucoup moins bien, je m'étonne même que tu arrives à établir une relation.

Si non, tu as la possibilité "classique" de déclarer deux tables dans la méthode form et d'établir ta liaison à l'aide d'une méthode where() ou andWhere().

Je reste convaincu que, hors exception exceptionnellement exceptionnel, toutes les relations ont intérêt à être définies dans le schéma de la base.

en faites, je gére des groupes de personnes d'un coté pour l'affichage et la mise à jour (GrpeChqDejList) et la gestion de Tickets restaurant par personne (ChqDej);
Les personnes peuvent changer régulièrement de groupe, donc le lien est peu important.

De plus quand j'ai voulu mettre une relation, celle ci étant 1 occurence de GrpeChqDejList => n occurences de ChqDej.
J'ai voulu la mettre dans GrpeChqDejList, hors quand je charge mes fixtures, ça plante car il veut a tout prix une valeur dans ChqDej, ce qui n'est pas logique !!!

je te remet mon schema tel que j'ai tenté de le faire passer:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

GrpeChqDejList: connection: doctrine tableName: GrpeChqDejList columns: grpechqdej_id: type: integer user_id: type: integer unique: true indexes: Unique: fields: [grpechqdej_id, user_id] type: unique relations: User: class: sfGuardUser local: user_id foreign: id GrpeChqDej: class: GrpeChqDej local: grpechqdej_id foreign: id #### ce que j'ai du retirer : ChqDej:: local: user_id foreign: user_id     ChqDej: connection: doctrine tableName: cheqdej columns: user_id: type: integer date: type: timestamp conges: type: integer maladie: type: integer professionel: type: integer nbChq: type: integer indexes: Unique1: fields: [user_id, date] type: unique relations: User: class: sfGuardUser local: user_id foreign: id onDelete: CASCADE onUpdate: CASCADE

---

A vue d'oeil, mais non testé.

Je pense que le problème de ta relation viens du fait que user_id dans GrpeChqDejList n'est pas clef primaire.

Si ta liaison partais de la clef primaire id de GrpeChqDejList ce qui me semblerais plus logique, tu ne devrais pas avoir de problèmes.

je pensait qu'il était préférable de laisser doctrine créer des id ?

bon pour info en fait le leftJoin ne fonctionne pas j'avais laissé une trace d'une relation entre les 2 que "j'ecrasait"

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

GrpeChqDejList: connection: doctrine tableName: GrpeChqDejList columns: grpechqdej_id: type: integer user_id: type: integer unique: true indexes: Unique: fields: [grpechqdej_id, user_id] type: unique relations: User: class: sfGuardUser local: user_id foreign: id GrpeChqDej: class: GrpeChqDej local: grpechqdej_id foreign: id ChqDej: connection: doctrine tableName: ChqDej columns: user_id: type: integer date: type: timestamp conges: type: integer maladie: type: integer professionel: type: integer nbChq: type: integer indexes: Unique1: fields: [user_id, date] type: unique relations: User: class: sfGuardUser local: user_id foreign: id onDelete: CASCADE onUpdate: CASCADE CheqDej: class: GrpeChqDejList local: user_id foreign: user_id

---

le probleme c'est pour garder l'historique d'un gars qui ne fait plus partie d'une liste !!!

PS: je pense devoir passer par $q = new Doctrine_rawSQL() mais pas compris comment ça marchait.

Effectivement si tu ne mets pas de clef primaire, doctrine en crée une.

Le problème est que dans ta relation, tu ne mets pas de clefs primaire. Et que je ne pense pas que symfony s'en sort.

Après, je ne comprend pas trop ce que tu veux faire avec tes trois tables (table user inclue). Le oncascade ne sert à rien si la liaison est basée sur une clef primaire autoincrémenté.

Pourrais-tu, avec des mots simple, décrire ce que tu souhaites réaliser ? (très simple les mots, j'ai un vocabulaire plutôt limité ;) )

on va essayer mais ça va etre dur :)
bon le principe:
gérer la commande tickets restaurant de tout les utilisateurs via des correspondants qui mettent à jour mensuellement les valeurs.

A la base, la table user qui n'est que la table sfGuardUser, je remet pas son schéma, je pense pas que ce soit utile.
Ensuite je gère des groupes avec un nom de groupe, un responsable, un suppleant.
c'est ma table GrpeChqDej:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

GrpeChqDej: connection: doctrine name: Type: String(50) primaryUser: Type: Integer secondaryUser: Type: integer relations: primaryUser: class: sfGuardUser local: primaryUser foreign: id secondaryUser: class: sfGuardUser local: secondaryUser foreign: id

---

ensuite pour chaque groupe je gere une liste de personne.
c'est la table GrpeChqDejList:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

GrpeChqDejList: connection: doctrine tableName: GrpeChqDejList columns: grpechqdej_id: type: integer user_id: type: integer unique: true indexes: Unique: fields: [grpechqdej_id, user_id] type: unique relations: User: class: sfGuardUser local: user_id foreign: id GrpeChqDej: class: GrpeChqDej local: grpechqdej_id foreign: id

---

bon la je pourrait peut etre mettre la relation GrpeChqDej dans la premiere table, serait plus logique, mais change pas grand chose à mon problème.

ça me permet tout les mois de n'afficher par responsable que sa liste
et enfin une table ou je gère les demandes par utilisateurs:
la table chqDej:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

ChqDej: connection: doctrine tableName: cheqdej columns: user_id: type: integer date: type: timestamp conges: type: integer maladie: type: integer professionel: type: integer nbChq: type: integer indexes: Unique1: fields: [user_id, date] type: unique relations: User: class: sfGuardUser local: user_id foreign: id onDelete: CASCADE onUpdate: CASCADE

---

et ce que je veut c'est pouvoir afficher lors de l'affichage d'un groupe la dernière date de mise a jour par user. Pour voir si tout le monde est à jour:

Code:

---

1 2 3 4 5

SELECT G.`user_id`, MAX(c.date ) FROM GrpeChqDejList G LEFT OUTER JOIN cheqdej c ON c.user_id=G.user_id WHERE G.`grpechqdej_id`=1 GROUP BY G.`user_id`

---

il est difficile de mettre une relation entre les 2 dernieres tables, car une personne ayant eu des cheque dej, peut ne plus être dans une liste et dans l'autre sens ce n'est pas parce que une personne est dans une liste qu'elle prend des cheq dej.

sinon tu ne pense pas que ce soit possible de créer ma requête via $q = new Doctrine_rawSQL() ?

Bien, cela commence à s'éclaircir un peu pour moi. Mais il me reste des zones d'ombre. Je vais reformuler.

Tu gères la répartition de chèques restaurants par personnes. Ces CR sont distribué par des responsables qui gères un groupe de personnes.

Une personne peut faire partie de plusieurs groupes. Les "achats (?)" de chèque sont stocké dans une table, chaque personne à une entrée par mois dans cette table si elle a commandé des chèques.

Les questions et remarques :

1. Est-ce que toutes les personnes qui sont toutes dans la tables sfGuardUser, doivent accéder à l'application ? Avoir un compte de connection et un mot de passe ? Pour faire leurs demande par exemple ? Si non, quel est l'intérêt de mettre les utilisateurs dans la table de validation des connexions ?
2. Dans la structure que tu proposes, une personnes peut faire partie de plusieurs listes, est-ce normal ? Où alors, elle peut changer de liste d'un mois sur l'autre ? Ou pires, être sur plusieurs listes pour un mois, avec plusieurs personnes qui doivent valider (il n'y a pas de champ de validation).
3. Le problème que tu as dans la relation est qu'il s'agit d'une relation n-n qui est mal définie, mais j'ai du mal à voir entre quels tables cette relation effectues.
4. Pourquoi dans la table ChDej trouve-t-on une date de demande, mais pas le mois et l'année d'imputation de la transaction ?
5. En fait, j'ai l'impression que tu devrait avoir une liaison 1-n entre l'utilisateur et le groupe (un utilisateur ne peut appartenir simultanément qu'à un groupe) et une liaison n-n pour les validations (ChDej) et les groupes, a raison d'une liaison par mois.
6. Quel est le niveau de responsabilité de la personne qui valide la demande ? Comment conserve-t-on l'historique de la personne qui à pris la décision (le premier, le second, quid d'un changement de responsable, il récupère les m.....e de son prédécesseur ?

Ce qui importe n'est pas là où tu définis la liaison, mais qu'elle soit définie et correctement définie.

La fonction Doctrine_rawSQL() va te permettre de faire à peut près n'importe quoi (avec les deux acceptations de l'expression), il faudrait plutôt la considérer comme un échec à mettre en place une bonne structure plutôt que comme une solution magique.

Dans une application de se type, une bonne analyse de la base de données est primordiale et évite bien des soucis. Focalise toi sur une structure viable (la tienne ne l'est pas encore), ensuite, dessiner l'application sera beaucoup plus naturel.

mouarf, bon vais essayer de te répondre point par point ;)

Citation:

---

Envoyé par mimi68

Une personne peut faire partie de plusieurs groupes. Les "achats (?)" de chèque sont stocké dans une table, chaque personne à une entrée par mois dans cette table si elle a commandé des chèques.

---

une personne peut changer de groupe mais jamais être dans 2 groupes différents

Citation:

---

Envoyé par mimi68

[*]Est-ce que toutes les personnes qui sont toutes dans la tables sfGuardUser, doivent accéder à l'application ? Avoir un compte de connection et un mot de passe ? Pour faire leurs demande par exemple ? Si non, quel est l'intérêt de mettre les utilisateurs dans la table de validation des connexions ?

---

pas forcément pour ce module, mais pour d'autre oui. Comme j'avais besoin de gérer pas mal d'info par utilisateur c'est toi qui m'avait suggérer d'utiliser ce plugin ;)

Citation:

---

Envoyé par mimi68

[*]Dans la structure que tu proposes, une personnes peut faire partie de plusieurs listes, est-ce normal ? Où alors, elle peut changer de liste d'un mois sur l'autre ? Ou pires, être sur plusieurs listes pour un mois, avec plusieurs personnes qui doivent valider (il n'y a pas de champ de validation).

---

surtout pas !!, une personne est forcément a un instant t que dans un seul groupe. d'ailleurs dans ma structure de table le user a un index unique:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

GrpeChqDejList: connection: doctrine tableName: GrpeChqDejList columns: grpechqdej_id: type: integer user_id: type: integer unique: true indexes: Unique: fields: [grpechqdej_id, user_id] type: unique relations: User: class: sfGuardUser local: user_id foreign: id GrpeChqDej: class: GrpeChqDej local: grpechqdej_id foreign: id

---

sauf que j'ai ça

Code:

---

1 2 3

Unique: fields: [grpechqdej_id, user_id] type: unique

---

en trop, vient de m'en apercevoir.

Pas de validation, en faites les responsables de groupe, ou leur suppléants saisissent les données à leur place (ce sont de gros feignants).

Citation:

---

Envoyé par mimi68

[*]Le problème que tu as dans la relation est qu'il s'agit d'une relation n-n qui est mal définie, mais j'ai du mal à voir entre quels tables cette relation effectues.

---

pas de liaison n-n
GrpeChqDej 1=>n GrpeChqDejList 1=>n (ou pas de relation) ChqDej
je peut avoir un enregistrement dans chqdej qui ne fait plus référence à une occurrence dans GrpeChqDejList

Citation:

---

Envoyé par mimi68

[*]Pourquoi dans la table ChDej trouve-t-on une date de demande, mais pas le mois et l'année d'imputation de la transaction ?

---

quand je gére des periode (ici année-mois), je trouve plus facile de gérer un champ date en forçant le jour à 1 plutôt qu'un champ année et un champ mois, comme ça je peut utiliser les fonctions Dates que ce soit dans SQL ou PHP.

Citation:

---

Envoyé par mimi68

[*]En fait, j'ai l'impression que tu devrait avoir une liaison 1-n entre l'utilisateur et le groupe (un utilisateur ne peut appartenir simultanément qu'à un groupe) et une liaison n-n pour les validations (ChDej) et les groupes, a raison d'une liaison par mois.

---

la je comprend pas tout mais je pense t'avoir répondu un peu plus haut.
par contre, effectivement, il n'y a pas validation par les responsables, mais bien juste la saisie pour un ensemble de personnes.

Citation:

---

Envoyé par mimi68

[*]Quel est le niveau de responsabilité de la personne qui valide la demande
? Comment conserve-t-on l'historique de la personne qui à pris la décision (le premier, le second, quid d'un changement de responsable, il récupère les m.....e de son prédécesseur ?

---

peut etre à origine de notre incompréhension mutuelle, il n'y a pas de notion de validations, juste une personne qui saisie à la place d'autre parce les autres sont faignant ;)

PS: bon il y a des trucs qui me dépassent. pour suivre tes conseils dans la table GrpeChqDejList, j'ai mis le champ user_id comme clef primaire.... sauf que si je fait ça il veut pas créer ma relation entre le champ user_id et sfGuardUser !!!

Le schema qui me semble le plus proche de tes besoins, tel que je les ais compris.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

user: inheritance: extends: sfGuardUser type: column_aggregation columns: GrpeChqDejList_id: integer relations: GrpeChqDej: local: id fogeign: user_id foreignAlias: users   ChqDej: tableName: cheqdej columns: user_id: type: integer date: type: timestamp conges: type: integer maladie: type: integer professionel: type: integer nbChq: type: integer indexes: Unique1: fields: [user_id, date] type: unique relations: User: local: user_id foreign: id foreignAlias: ChqDejs onDelete: CASCADE   GrpeChqDej: name: type: String(50) notnull: true primary_user_id: Type: Integer notnull: true secondary_user_id: Type: integer relations: primaryUser: class: user local: primary_user_id foreign: id secondaryUser: class: user local: secondary_user_id foreign: id

---

Remarques :

• La table GrpeChqDejList a disparu, elle ne servait qu'à établir un lien hypothétique avec les user et rajoutait une couche d'incertitude dans la gestion de la base.
• Pour bien gérer il aurait fallu avoir un champs supplémentaire dans la table user, le numéro (id) du groupe du user (qui serait donc unique d'office). Ce qui est fait grâce à la table user qui étant par héritage la table sfGuardUser et lui rajoute un champs : GrpeChqDejList_id pour la lisaison et la relation qui va avec. Attention, seul la table user possède cette relation et ce champ, elle possède, de plus tous les champs de sfGuardUser ainsi que leurs relation. Dans ton schéma, tu feras référence à la table user la majeur partie du temps, sauf pour la gestion des droits qui va travailler sur sfGuardUser, et tous va marcher. sisi.
• Modification du lien entre la table user et la table ChqDej.
• Quelques simplifications et allégements
• Modification des liens dans la table GrpeChqDej pour qu'ils pointent sur user

Avec ce schéma :

• un user ne peut faire partie que d'un groupe
• un user peut avoir au maximum une ligne de commande par mois
• un user peut ne pas avoir de ligne de commande

On doit être assez proche de tes demandes.

Ta première requête s'écrit alors :

Code:

---

1 2 3 4 5 6

$q = Doctrine_Query::create() ->from('user u') ->leftJoin('u.ChqDejs c') ->select('u.id, MAX(c.date)') ->execute();

---

Comme quoi, un bon schéma simplifie les requêtes.

la table que tu supprime était du au fait que je gère les chqdej pour un site mais que ma table user contient l'ensemble des utilisateurs européens.

pour éviter d'avoir un champ inutile dans 70% des cas, j'avais préféré créer cette table intermédiaire.

je modifie mon schéma et te dit :)

Note que tu peux rajouter un champ pays dans la table étendue user. Ce qui peut servir. Et un champs service, et un téléphone et... bien d'autres informations intéressantes.

Il est vrais que dans ce cas là, le champ de liaison n'aurait d'intérêt que pour un pays, ce qui n'est pas optimal.

On pourait envisager une table de jointure entre la table user et le système de chèque, avec une liaison 1-0<->1-1 faut voir si cela (la solution dans user) surcharge trop le format global de la base.

la table user posséde dja une dizaine de champ supplémentaire donc un de plus...

par contre pour le moment j'ai un bléme, malgré le fait que j'ai supprime la table grpChqDejList de mon schéma, elle réapparait systématique à chaque build (j'ai drop le schéma depuis mySQL pour être sur) :cfou:

Code:

---

symfony doctrine:delete-model-files

---

trop tard, j'ai tout supprimé :)
mais bon à savoir ;)

bon bein message d'erreur :(
mon schema:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89

user: inheritance: extends: sfGuardUser type: column_aggregation actAs: [Timestampable] columns: matricule: type: integer unique: true epass: type: string(20) unique: true section_id: { type: integer } emailintranet: type: string(255) unique: true site_id: { type: integer } contrat: { type: string(3) } esi: type: boolean default: 0 GrpeChqDejList_id: type: integer startdate: type: timestamp gardenleavedate: type: timestamp offrolldate: type: timestamp relations: Section: local: section_id foreign: id onDelete: CASCADE Site: local: site_id foreign: id GrpeChqDej: local: id foreign: user_id foreignAlias: users   GrpeChqDej: tableName: GrpeChqDej columns: name: type: string(50) notnull: true primary_user_id: type: integer notnull: true secondary_user_id: type: integer relations: primaryUser: class: user local: primary_user_id foreign: id secondaryUser: class: user local: secondary_user_id foreign: id   ChqDej: tableName: cheqdej columns: user_id: type: integer date: type: timestamp conges: type: integer maladie: type: integer professionel: type: integer nbChq: type: integer indexes: Unique1: fields: [user_id, date] type: unique relations: User: class: user local: user_id foreign: id foreignAlias: ChqDejs onDelete: CASCADE

---

Citation:

---

Unknown record property / related component "grpe_chq_dej_list_id" on "user"

---

je rebuild, je charge mes données et quand je fait /guard/users, j'obtient ce message:

C'est le problème avec les notation en xxx_yyy et XxxYyy.

C'est pourquoi, par paresse, je n'ai jamais de nom composé dans les schémas.

De tête, dans le shema.yml la notation doit se faire sous la forme xxx_yyy pour tous les champs. Et si possible tous en minuscule.

Il convient donc de transformer : GrpeChqDejList_id en grpe_chq_dej_list_id

A priori, cela n'est important que pour les noms de champs. Mais j'avoue que j'aurais dû faire plus d'essais la dessus.

ça marche !!!
enfin sauf pour la création de table user:

Citation:

---

user:
inheritance:
extends: sfGuardUser
type: column_aggregation
columns:
GrpeChqDejList_id: integer
site_id: integer
relations:
GrpeChqDej:
local: id
fogeign: user_id
foreignAlias: users
Site:
local: site_id
foreign: id

---

en faites les relations que je rajoute à cette table style le site n'est pas pris en compte dans le formulaires.
Ce que je veut dire, c'est que dans la page de guard/users si je veut filtrer par site, je doit rajouter:

Code:

---

1 2	filter: display: [last_name, matricule, epass, site_id]

---

et il m'affiche un champ texte ou je doit rajouter l'id du site, pas trés convivial.
de même pour le formulaire d'édition ou de création d'un user.

Par contre si j'écrase le schéma de sfGuardUser par mon propre shéma, ça marche.
A savoir, je pense ;)

Il y a deux manières d'étendre la table sfGuardUser, chacune avec ces avantages et ces inconvénients.

Celle que tu utilise vaut l'autre, si elle te convient mieux, c'est que c'est la bonne pour l'application que tu développe.