[sf 1.4.x] Des fixtures ne se chargent plus sans erreur

[CaraG33k]

Bonjour,

Pour un projet, j'avais des fixtures de test qui se chargeaient correctement... jusqu'à aujourd'hui où je décide de mettre à jour sfDoctrineGuardPlugin (avec mise à jour des fixtures correspondantes) et de passer symfony à la version svn de la branche 1.4 (avec un svn:external).

Code :

./symfony doctrine:build --all --and-load

se déroule sans erreur.

Je teste mon appli et me rend compte qu'il ne trouve plus les données de 2 tables (pour toutes les autres, c'est bon, sfGuard* comprise). Effectivement phpMyAdmin me renvoie des tables vides.

Code :

1
2
3
$ ./symfony doctrine:data-load data/fixtures/fac.yml      
>> doctrine  Loading data fixtures from "data/fixtures/fac.yml"
>> doctrine  Data was successfully loaded

Et pourtant, la table est toujours vide sous phpMyAdmin... Et je n'ai même pas de message d'erreur à me mettre sous la dent.

Quelqu'un a-t-il déjà eu ce comportement étrange ? Une idée ? ...avant que je ne me décide à faire marche arrière sur la version mineure de Symfony.

[Michel Rotta]

Un peu rapide comme retour en arrière.

Tu peux donner ton shema (au moins pour la table qui pose problème et celle liée. Ainsi que le fixture correspondant.

Le message d'erreur, c'est bien, les données pour y voir clair, c'est mieux !

[CaraG33k]

Je vais prendre l'exemple le plus parlant qui fait que je ne comprends pas le comportement.

schema.yml : les deux se créent sans problème.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
CopisimFac:
  columns:
    periode: { type: integer, notnull: true }
    titre: { type: string(255), notnull: true }
  relations:
    CopisimPeriode: { local: periode, foreign: id }
 
CopisimRegion:
  columns:
    periode: { type: integer, notnull: true }
    titre: { type: string(255), notnull: true }
  relations:
    CopisimPeriode: { local: periode, foreign: id }

fixture/fac.yml (load successful mais rien dans la table) :

Code :

1
2
3
4
CopisimFac:
  Marseille:
    CopisimPeriode: 2009
    titre: Aix-Marseille

fixture/region.yml (ne pose pas problème) :

Code :

1
2
3
4
CopisimRegion:
  1:
    CopisimPeriode: 2009
    titre: Aix-Marseille

Accessoirement, j'ai aussi testé avec la 1.4.8 du dépot Gentoo, avec strictement le même résultat. Tout fonctionnait correctement et il me semble que c'était avec la 1.4.4... Je jetterai demain un coup d'oeil aux changelogs des 5, 6, 7 et 8 et je retesterai à côté avec la 1.4.4...

[Michel Rotta]

C'est un traitement doctrine, pas symfony. A ma lecture du changelog de symfony, il n'y pas de modification de la version de doctrine embarqué entre la 1.4.4 et la 1.4.5. Le seul changement est entre la 1.4.6 et la 1.4.7 et concerne le chargement du doctrine_core, rien a voir avec les fixatures.

Je te propose de faire un projet de test, d'y mettre ce mini schema (peut-être avec la table de liaison) et de tester ton fixature au milieu d'un projet vierge. Pour voir.

Je pense que cela devrait marcher.

Question annexe, es-tu sur de l'unicité des noms des objets ajoutés "Marseille" et "1" ? Ils doivent, dans mes souvenirs, être uniques, toutes tables confondues, tous fichiers de fixatures confondus.

[CaraG33k]

Je vais tester ça.

Pour les noms des objets, je pense qu'ils doivent être unique au niveau de la table, pas sur l'ensemble des fixatures (puisqu'ils sont appelés par table: nom_objet). D'ailleurs "Marseille" est unique sur l'ensemble des fichiers mais pas "1" (or le problème se situe à l'inverse).

[CaraG33k]

Bon après divers tests à tâtons :

• Sur un projet vierge, j'ai le même comportement pour la version svn de Symfony si je copie simplement le schema.yml et les fixtures
• En réduisant le schema.yml à son plus simple appareil, même comportement
• Si je limite les fixtures aux 4 premiers enregistrements, ça les charge normalement : il y a bien un problème quelque part dans le fichier fac.yml
• Il y avait dans fac.yml des champs "titre" contenant une valeur avec une erreur d'encodage des accents, leur correction ne change rien ; il n'y en a pas dans etudiant.yml (un gros fichier ceci dit)
• Ca fonctionne correctement avec la version 1.4.7 et la 1.4.8 de Symfony téléchargées sur le site

Du coup, je pense que je vais abandonner simplement le svn:externals sur la branche 1.4 (pourtant techniquement plus propre), pour me contenter du tar de la dernière version stable.

[Michel Rotta]

Le svn est a réserver pour des tests d'évaluations.

Attention, les fixtures ne sont pas destiné à récupérer une base existante et j'ai vu symfony planter en téléchargement de gros fixture.

Symfony télécharge tous les fichiers fixture avant de les traiter, pour vérifer les enchainement de création à faire. Donc le fait de séparer en plusieurs fichier donne un confort de lecture, mais ne factorise en rien les traitements.

Tu peux mettre le fichier complet (au moins les premier 10) pour ton fixture fac ?

[CaraG33k]

De toute façon, ça marche parfaitement avec les versions téléchargées, donc je me suis rabattu sur celles-ci.

Je sais bien que le découpage ne me fait rien gagner sur le traitement des données mais pour le gros fichier (etudiant.yml), jusque là ça passait et ça me permet de faire des tests au plus près des simulations précédente (c'est une migration vers symfony) pour y détecter les éventuels comportement anormaux. Tout ça, je le virerai avant d'entrer en production (et quand j'aurais écrit les différentes fonctions d'import).

Pour le fac.yml (complet) :

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
CopisimFac:
  Marseille:
    CopisimPeriode: 2009
    titre: Aix-Marseille
  Amiens:
    CopisimPeriode: 2009
    titre: Amiens
  Angers:
    CopisimPeriode: 2009
    titre: Angers
  Besancon:
    CopisimPeriode: 2009
    titre: Besancon
  Bordeaux1:
    CopisimPeriode: 2009
    titre: Bordeaux 1
  Bordeaux2:
    CopisimPeriode: 2009
    titre: Bordeaux 2
  Bordeaux3:
    CopisimPeriode: 2009
    titre: Bordeaux 3
  Brest:
    CopisimPeriode: 2009
    titre: Brest
  Caen:
    CopisimPeriode: 2009
    titre: Caen
  Ferrand:
    CopisimPeriode: 2009
    titre: Clermont-Ferrand
  Dijon:
    CopisimPeriode: 2009
    titre: Dijon
  Grenoble:
    CopisimPeriode: 2009
    titre: Grenoble
  Etat:
    CopisimPeriode: 2009
    titre: Lille Etat
  Catho:
    CopisimPeriode: 2009
    titre: Lille Catho
  Limoges:
    CopisimPeriode: 2009
    titre: Limoges
  GrangeBlanche:
    CopisimPeriode: 2009
    titre: Lyon Grange-Blanche
  Laennec:
    CopisimPeriode: 2009
    titre: Lyon Laennec
  Nord:
    CopisimPeriode: 2009
    titre: Lyon Nord
  Sud:
    CopisimPeriode: 2009
    titre: Lyon Sud
  Montpellier:
    CopisimPeriode: 2009
    titre: Montpellier-Nîmes
  Nancy:
    CopisimPeriode: 2009
    titre: Nancy
  Nantes:
    CopisimPeriode: 2009
    titre: Nantes
  Nice:
    CopisimPeriode: 2009
    titre: Nice
  Bobigny:
    CopisimPeriode: 2009
    titre: Paris Bobigny
  Creteil:
    CopisimPeriode: 2009
    titre: Paris Créteil
  Descartes:
    CopisimPeriode: 2009
    titre: Paris Descartes
  Bicetre:
    CopisimPeriode: 2009
    titre: Paris Kremlin-Bicêtre
  Ouest:
    CopisimPeriode: 2009
    titre: Paris Ouest
  Antoine:
    CopisimPeriode: 2009
    titre: Paris Saint-Antoine
  Pitie:
    CopisimPeriode: 2009
    titre: Paris Pitié-Salpétrière
  VII:
    CopisimPeriode: 2009
    titre: Paris VII
  Poitiers:
    CopisimPeriode: 2009
    titre: Poitiers
  Reims:
    CopisimPeriode: 2009
    titre: Reims
  Rennes:
    CopisimPeriode: 2009
    titre: Rennes
  Rouen:
    CopisimPeriode: 2009
    titre: Rouen
  Etienne:
    CopisimPeriode: 2009
    titre: Saint-Etienne
  Strasbourg:
    CopisimPeriode: 2009
    titre: Strasbourg
  Purpan:
    CopisimPeriode: 2009
    titre: Toulouse Purpan
  Rangueil:
    CopisimPeriode: 2009
    titre: Toulouse Rangueil
  Tours:
    CopisimPeriode: 2009
    titre: Tours
  Europe:
    CopisimPeriode: 2009
    titre: Europe

[Michel Rotta]

A priori tes données devraient passer.

Par contre il faut faire attention, le système des fixatures n'est pas conçu pour traiter des migrations. Il est conçu pour alimenter la base pour des test avec une base toujours identique pour permettre d'avoir un socle stable pour ses tests.

Je crains que, pour je ne sais quel raison, tu étais juste en dessous de la possibilité de mémoire et que là, tu es passé au dessus. Sans que cela soit nécessairement lié à symfony.

Pour de gros ajouts de données, le sql présente pas mal d'avantage en terme de stabilité.

[erictomcat]

les fichiers fixtures semble avoir un comportement assez chaotique dés que tu dépasse un certains nombre de lignes (plus de 5).
Des tables se chargent mais oublie des enregistrements complets, d'autres charge tout les enregistrements mais pas forcément avec tout les champs.

pas de message d'erreur, rien.
Je me suis finalement rabattu avec un lien ODBC et une base access et je charge mes données via une macro quand j'ai besoin de tester sur un nombre conséquent de données.