champs Invalid dans formulaire

[flora806]

Bonjour,

J'ai un souci avec la validation d'un formulaire dans symfony, il s'agit d'un formulaire dans un module que j'ai créé pour la gestion des livraisons de produits faisant parties de Packages:
Voici une partie de mon schema.yml de la table concernée:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
LivraisonPackageArticle
connection: doctrine
  tableName: articlepackage
  columns:
    article_id:  
	  type: integer
	  notnull: true
	  primary: true 
    package_id:  
	  type: integer
	  notnull: true
	  primary: true 
	quantite:
	  type: integer
	..................
  relations:	  
    Article: { onDelete: RESTRICT, local: article_id, foreign: id}
    Package:   { onDelete: RESTRICT, local: package_id, foreign: id}

Afin d'éviter d'avoir dans le formulaire des Id pour les articles et les packages, j'ai rajouté une méthode __toString() dans les classes "Article" et "Package" afin de récupérer le nom à la place.
et grâce à ça j'ai des listes déroulantes pour article et package dans le formulaire.
mais quand je crée une nouvelle livraison et je fais save, j'ai l'erreur "Invalid" devant les champs de noms d'Article et package .

A votre avis, ça vient de quoi ce problème: de la méthode __toString(), des validateurs...? je cherche mais je trouve pas encore

[flora806]

Je pense pas que ça ne vient pas de la méthode __toString(), je viens de tester en la supprimant et j'ai toujours "Invalid"..
voici la partie du code générée par symfony dans le controller qui est sensé traiter le formulaire:

Code :

1
2
3
4
5
6
7
8
9
10
 
protected function processForm(sfWebRequest $request, sfForm $form)
  {
    $form->bind($request->getParameter($form->getName()), $request->getFiles($form->getName()));
    if ($form->isValid())
    {
      $article_package = $form->save();
...
    }
  }

[Michel Rotta]

Je pencherais pour un problème lié au schéma (disons dans les 30% de probabilités).

Essaye avec un schéma modifié ainsi

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
LivraisonPackageArticle
  connection: doctrine
    tableName: articlepackage
  columns:
    article_id:  integer
   package_id: integer
  quantite: integer
	..................
  relations:	  
    Article: 
      foreignAlias: LivraisonPackageArticles
    Package:
      foreignAlias: LivraisonPackageArticles

Dans tous les cas, et sauf en cas d'une table pivot, la clef primaire double n'est pas correctement gérée par symfony.
Dans le cadre d'une table de liaison pour une liaison n-n, c'est ce que l'on fait généralement, mais avec des arguments sur la liaison, c'est beaucoup plus discutable, tout dépend e ce qui se cache derrière les ..... et dans le reste du schema.

Il est possible de rajouter un index unique sur les deux clefs pour s'assurer de l'unicité de la relation, mais je pense qu'ici on doit pouvoir envisager plusieurs lignes avec des quantités différentes.

Attention à ne pas avoir de relations réciproques que Package et Article.

[flora806]

Dans le cadre d'une table de liaison pour une liaison n-n, c'est ce que l'on fait généralement, mais avec des arguments sur la liaison, c'est beaucoup plus discutable, tout dépend e ce qui se cache derrière les ..... et dans le reste du schema.

il s'agit d'une table de liaison n-n qui contient 2 clés étrangères (articleId) et (packageId) et qui contient en plus:
- 'nbr_pieces'
- 'quantite_par_piece'
- 'unite'

Attention à ne pas avoir de relations réciproques que Package et Article.

j'ai pas du tout de relations réciproques dans Package et Article.

Il est possible de rajouter un index unique sur les deux clefs pour s'assurer de l'unicité de la relation, mais je pense qu'ici on doit pouvoir envisager plusieurs lignes avec des quantités différentes.

oui j'ai plusieurs lignes avec des quantités de produits différentes à chaque fois.

Si je mets à jour le schema.yml, cela ne risque pas d'écraser toutes classes et mes fichiers Form...j'ai fait qq modifications et j'ai pas envie de les perdre.

[Michel Rotta]

oui j'ai plusieurs lignes avec des quantités de produits différentes à chaque fois.

Avec le schéma que tu m'as montré, ce n'est pas possible. Donc le schéma n'est pas le bon et il faut l'optimiser.

Tu as donc trois tables avec deux relations 1-n et non pas deux tables avec une relations n-n avec des arguments qui en génère une troisième (table) pour la liaison.

Il faut que la table "LivraisonPackageArticle" bénéficie de son propre Id.

Quant tu régénères, tu effaces tous ce qui se trouve dans lib/modeles/doctrine/base, lib/form/doctrine/base et lib/filter/doctrine/base. Si tu y a fait des modifications (ce qui est plus que fortement décommandé) il faudra les reporter sur les fichiers dans doctrine/ de chacun des trois.

Attention, toutes les données de la base régénérée sont perdues. En principe elles proviennent d'un "fixature" donc pas de problème.

Si tu as bien pris tes précautions il n'y a aucun inconvénient à régénérer. Pense à faire un cc après. Je régénère très souvent dans mes projets.

[flora806]

oui j'ai plusieurs lignes avec des quantités de produits différentes à chaque fois.

Avec le schéma que tu m'as montré, ce n'est pas possible. Donc le schéma n'est pas le bon et il faut l'optimiser.

En fait je ne sais pas si on parle de la même chose:
selon mon schema, j'obtiens une table "LivraisonPackageArticle" où chaque ligne se présente comme ça:
packageId, articleId, nbr_pieces, quantite_par_piece, unite
sachant que j'obtiens plusieurs lignes pour un même packageId, puisqu'il contient différentes quantités de 1,n articles.
on l'a discuté aussi dans :
http://www.developpez.net/forums/d10...alculer-somme/

Tu as donc trois tables avec deux relations 1-n et non pas deux tables avec une relations n-n avec des arguments qui en génère une troisième (table) pour la liaison.

oui j'ai bien 3 tables avec 2 relations 1,n et j'ai pas d'id spécifique à la table "LivraisonPackageArticle", ça serait quoi l'intérêt d'en avoir un?

tu penses que cette conception n'est pas la bonne?

[Michel Rotta]

Je ne m'était pas penché sur le schéma dans l'autre sujet.

Si tu peux avoir deux lignes pour le même pakage et le même article avec une différence sur l'un des : nbr_pieces, quantite_par_piece, unite.

Alors oui, tu as un problème dans ton schéma qui interdit explicitement (de par la clef) ce type de chose.

De plus, si tu veux, un jour, partir de cette table pour aller vers une autre (une liaison 1-n ou cette table serait 1) alors là, tu auras un problème (ce jours là).

Si non, ton schéma est viable.

[flora806]

Si tu peux avoir deux lignes pour le même pakage et le même article avec une différence sur l'un des : nbr_pieces, quantite_par_piece, unite.

Alors oui, tu as un problème dans ton schéma qui interdit explicitement (de par la clef) ce type de chose.

Non, en fait si un package contient 2 articles différents par exp, j'obtiens deux lignes pour le même packageId mais avec des articlesId différents et des quantités différentes.
là ça te paraît correct?

[Michel Rotta]

Si tu as la situation tel que tu le décris et que "jamais il n'y aura la demande d'avoir deux articles différents dans un package parce que c'est sémantiquement impossible", alors oui, c'est correcte.

Mais si j'avais à faire ce type de développement, je mettrais un id indépendant de tous liens pour cette table, les deux champs en relations, un index sur ces deux champs pour m'assurer de leur unicité.

Ainsi j'ai le même comportement que toi et, le cas échéant, la possibilité de le changer facilement (suppression de l'index unique sur les deux champs) avec un minimum d’impact sur le reste de l'application.

Ça ne veux pas dire que ce que tu fais est faux, juste que mon approche serait différente. J'ai vu tellement de spécifications inamovibles être modifiées une fois les premiers écrans dans les mains des utilisateurs sur des projets mal étudiés que je préfère prévoir que guérir.

[flora806]

Quant tu régénères, tu effaces tous ce qui se trouve dans lib/modeles/doctrine/base, lib/form/doctrine/base et lib/filter/doctrine/base. Si tu y a fait des modifications (ce qui est plus que fortement décommandé) il faudra les reporter sur les fichiers dans doctrine/ de chacun des trois.

en fait pour regénérer, il faut utiliser quelle commande?
doctrine:build --model
doctrine:build --sql
..

donc c sûr que les classes ne sont pas remplacées avec la regénération?

[Michel Rotta]

La commande que j'utilise est

Code :

symfony doctrine:build --all --no-confirmation --and-load

Elle supprime la base de données et la recrée, elle supprime et recrée tous les fichier base et les recrées, elle charge les fixatures définies.

donc c sûr que les classes ne sont pas remplacées avec la regénération?

Les classes bases sont supprimées. Elle sont conçues par sensio pour l'être. Si tu ne les as pas modifié, aucuns risques. Si tu les as modifiés tu as fait une erreur et il faut déplacer le code dans les classes enfants.

Dans tous les cas et si tu as un doute, une copie préalable de sauvegarde est rapide et sur. Et faire régulièrement un freez de son développement évite de mauvaises surprises.

[flora806]

j'ai essayé d'optimiser le schema.yml en suivant tes conseils que tu m'avais fourni dans une autre discussion:

* Pas de valeur par défaut déclarée au shema.yml
* dans la relation, local a par défaut le nom de la classe en relation plus "_id" donc on laisse par défaut.
* dans la relation, foreign a par défaut "id"...
* dans la relation, foreignAlias a par défaut la classe de définition de la relation (ici ArticleLivre). Je remplace par ArticleLivres (avec "s") pour indiquer qu'il y a plusieurs ArticleLivre pour un article. Le foreignAlias est le nom de la relation vue depuis la classe de l'autre côté de la relation.
* Mettre une longueur a string, si non il fait un champ trop grand et mange de la place inutilement.
* Si pas de clef primaire définie il en crée une par défaut (Id, integer).
* Pour la lisibilité, il faut éviter de mélanger les syntaxe de base et par {} dans le shema.

et là c'est la cata j'ai une erreur SQL:

Code :

1
2
3
SQLSTATE[42000]
syntax error or access violation: 1064 that corresponds to Mysql version or syntax to use near, created_at  DATETIME notnull....
Failing query create table ArticleLivreFournisseur <Id BIGINT autoincrement....>

je déprime tout ce que je voulais c'est optimiser le yml et régler le probleme des champs invalid..

[flora806]

Bon, j'ai pu finalement résoudre ce problème d'erreur SQL et de mise à jour du schema.yml

Maintenant je reteste le prb des champs invalid dans le formulaire, j'ai plus de problèmes pour les champs "ArticleId" et "PackageId", mais ça m'affiche l'erreur :

Code :

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

En fait l'enregistrement est bien inséré dans la base de données et il s'affiche sur la liste des livraisons, mais je comprens pas pourquoi cette erreur s'affiche

j'ai l'impression que ça vient de l'Id de cette table qui est en principe caché, mais normalement ça doit s'incrémenter automatiquement.

[Michel Rotta]

Le fait de me redonner des informations d'optimisation que je donne régulièrement ne peux me permettre de comprendre ce que tu as fais...

Donne moi plutôt ton shema.yml.

[flora806]

voici la table concernée dans le schema.yml

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
 
ArticleIntegrePackage:
  connection: doctrine
  tableName: articlepackage
  columns:
    article_id:  
      type: integer
      notnull: true 
    package_id:  
      type: integer
      notnull: true         
    nbr_pieces:
      type: integer(4)
    quantite_par_piece:
      type: integer(4)
    unite:
      type: string()
    date_livraison:
      type: date(25)
  relations:	  
    Article: 
      foreignAlias: ArticleIntegrePackages
    Package:
      foreignAlias: ArticleIntegrePackages

En vérifiant la base de données MySQL qui été recréé, en plus des champs présentés ici, je vois bien un id qui a été rajouté à la table correspondant à "ArticleIntegrePackage".

[Michel Rotta]

Dans ce bout de schéma, le type date(25) ne correspond à rien. Le type doit être date.

Je ne peux voir ton problème sur un si petit bout. Donc, sauf si le schema est monstrueux (en taille), pourrais-tu mettre le schema ?

En vérifiant la base de données MySQL qui été recréé, en plus des champs présentés ici, je vois bien un id qui a été rajouté à la table correspondant à "ArticleIntegrePackage"

Il n'est pas normal que doctrine 1.2 interprète ton schéma et crée seul des champs supplémentaires.

[flora806]

oui mon schéma est énorme, là je te mets la descritpion de toutes les tables concernées:

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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
 
Fabriquant:
  connection: doctrine
  tableName: fabriquant
  actAs: { Timestampable: ~ }
  columns:
    nom_fabriquant:
      type: string()
    user_creation:
      type: string()
    user_maj:
      type: string()
Fournisseur:
  connection: doctrine
  tableName: fournisseur
  actAs: { Timestampable: ~ }
  columns:
    nom_fournisseur:
      type: string()
    user_creation:
      type: string()
    user_maj:
      type: string()
Package:
  connection: doctrine
  tableName: package
  actAs: { Timestampable: ~ }
  columns:
    id:  
      type: integer
      notnull: true
      primary: true  
    code_package:
      type: integer(4)
    nom_package:
      type: string()
    n_inventaire_package:
      type: string()
    user_creation:
      type: string()
    user_maj:
      type: string()
Stock:
  connection: doctrine
  tableName: stock
  actAs: { Timestampable: ~ }
  columns:
    batiment_id:
      type: integer
      notnull: true
    numero:
      type: string()
    user_creation:
      type: string()
    user_maj:
      type: string()
  relations:
    Batiment:
      onDelete: RESTRICT
      foreignAlias: Stocks    
ArticleFabrique:
  connection: doctrine
  tableName: articlefabrique
  columns:
    article_id:
      type: integer
      notnull: true  
    fabriquant_id: 
      type: integer
      notnull: true   
  relations:	  
    Article: 
      onDelete: RESTRICT
      foreignAlias: ArticleFabriques  
    Fabriquant: 
      onDelete: RESTRICT
      foreignAlias: ArticleFabriques 	
ArticleIntegrePackage:
  connection: doctrine
  tableName: articlepackage
  columns:
    article_id:  
      type: integer
      notnull: true 
    package_id:  
      type: integer
      notnull: true         
    nbr_pieces:
      type: integer(4)
    quantite_par_piece:
      type: integer(4)
    unite:
      type: string()
    date_livraison:
      type: date
  relations:	  
    Article: 
      foreignAlias: ArticleIntegrePackages
    Package:
      foreignAlias: ArticleIntegrePackages
ArticleLivreFournisseurStock:
  connection: doctrine
  tableName: articlefournisseurstock
  actAs: 
    Timestampable: ~
  columns:
    article_id:  
      type: integer
      notnull: true 
    fournisseur_id:
      type: integer
      notnull: true 
    stock_id: 
      type: integer
      notnull: true 
    date_livraison:
      type: date(25)
    nombre_pieces:
      type: integer(4)
    quantite_par_piece:
      type: integer(4)
    unite:
      type: string()
  relations:	  
    Article: 
      onDelete: RESTRICT
      foreignAlias: ArticleLivreFournisseurStocks
    Fournisseur:
      onDelete: RESTRICT 
      foreignAlias: ArticleLivreFournisseurStocks
    Stock:
      onDelete: RESTRICT
      foreignAlias: ArticleLivreFournisseurStocks
Article:
  connection: doctrine
  tableName: article
  actAs: { Timestampable: ~ }
  columns:
    id:  
      type: integer
      notnull: true 
      primary: true
      autoincrement: true 
    forme_id: 
      type: integer
      notnull: true    
    nom:
      type: string()
      notnull: true
    nom_categorie:
      type: enum(25)
      values:
        ....
 
      notnull: true
    n_inventaire:
      type: string()
	...............................  
    creation_user:
      type: string()
    update_user:
      type: string()
  relations:	  
    Forme:
      onDelete: RESTRICT 
      foreignAlias: Articles

ce que j'ai remarqué, c'est que dans toutes les tables de liaison par exp "ArticleLivreFournisseurStock", "ArticleFabrique", "ArticleIntegrePackage", quand la base de données est générée un id (clé primaire) est rajouté automatiquement à ces tables.
et normalement tu m'avais dis précédemment qu'il vaut mieux avoir cet id là, qu'une clé primaire composée de 2 ou 3 clés étrangères puisque symfony gère mal ça.

Alors, j'ai juste l'impression que l'erreur

Code :

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

est liée à cet id.
Quand je fais "New" dans "ArticleIntegrePackage" représentant une nouvelle livraison d'un package, l'Id (clé primaire) n'est pas visible sur le formulaire. En validant l'erreur apparait, mais l'enregistrement est quand même sauvegardé dans la BD

[Michel Rotta]

Doctrine (et pas symfony) a quelques particularités.

Il gère mal les relations avec des clefs primaires multiples, mal celle à deux clef et pas du tout au delà.

Par contre il exige que chaque table dispose d'une clef primaire, en principe de quoi, s'il n'y en a pas de déclarée, il va créer automatiquement un champ id (integer ou bigint) auto incrémenté.

A partir de la dernière version de doctrine, il va le créer en bigint.

De plus, pour les liaison, vu comment tu les déclares (et tu les déclares bien), il va chercher à lier un champ id avec un champs nomtable_id. D'où l'importance de conserver les conventions de nommage. Il peut arriver que cela ne soit pas possible, on peut alors lui indiquer les champs à lier.

Pour ton problème, je soupcones que tu travails en 1.4.8 ou plus (ce qui est bien) et que les clefs primaires auto générée le soient en bigint et pas integer. Ce qui pourrait expliquer impossibilité de créer des liaisons entre un integer et un bigint et pourrait expliquer le message d'erreur.

Essaye de remplacer les type: integer dans tes tables par des type: bigint.

Si non, il reste la méthode que j'utilise dans les cas désespéré. Je supprime un grand nombre de tables du schéma et génère la base, puis je rajoute par paquet de table jusqu'à trouver le paquet qui va provoquer l'erreur. Puis je test les tables du paquet pour trouver celle qui génère l'erreur, puis les champs et les liaisons... Un peu long, mais efficace quant je ne sais plus où donner de la tête.

J'ai parcouru ton schéma, à part le type: date(25) qui me semble toujours aussi faux, je ne vois pas de problèmes particuliers.

[flora806]

Merci Michel,
je galère toujours avec cette erreur SQLSTATE[HY093]..
je travaille bien avec la version 1.4.8 de symfony. Alors j'ai essayé de remplacer les types integer par BIGINT partout où il y a des clés. j'ai supprimé aussi le date(25)..MAIS j'ai toujours la même erreur
j'ai pas encore essayé ta solution de cas désespéré..peut être que je vais finir par le faire à moins que tu aies une autre idée!!

[Michel Rotta]

Il ne faut pas supprimer "date(25)" mais le remplacer par "date".

Pour integer et/ou bigint pas d'avis.

Pour ton message d'erreur, j'ai une autre piste. Il est possible que tu ai, sur une table, une clef multiple et que tu tentes de mettre cette table en relation avec une autre dans une liaison 1-n. Ce qui n'est pas possible avec doctrine 1.2.

Si non, ma solution de test m'a déjà souvent sorti de situation à priori inextricables.