[sf 1.4.x] charger des data via fichier sql

[erictomcat]

bonjour, du fait d'une appli un peu volumineuse, je ne peut pas charger mes données de test via les fixtures.
Y a t il un moyen de les charger à partir d'un fichier sql ?

[Maerlyn31]

Hello,

Si ce SQL ne concerne que des données, et pas du tout la structure, qui elle est configurée proprement dans le schema.yml (avec classes, SQL et BDD générés via Doctrine), tu peux très bien charger ton fichier SQL de manière "classique" via PhpMyAdmin ou directement dans le prompt SQL, celà n'aura pas d'incidence sur le fonctionnement de ton appli.

[erictomcat]

oui effectivement, c'est ce que je fait.
Mais pour la base de test que je souhaite "réinitialisé" a chaque début des test, je préférerai que cela soit inclus dans le processus symfony.
Du style en remplaçant le

Code :

Doctrine_Core::loadData(sfConfig::get('sf_test_dir').'/fixtures');

ça m'éviterait de lancer les test en oubliant de la réinitialisation

[Maerlyn31]

Hmmm ...

Tu peux faire exécuter du code arbitrairement à Doctrine avec la technique suivante :

Code :

1
2
3
4
// récupération de la connexion
$con = Doctrine_Manager::getInstance()->connection();
// ta requête SL
$st = $con->execute("...............");

Avec un file_get_contents pour récupérer ton contenu SQL, ça peut "théoriquement" le faire. Cependant, si tes données de test sont trop volumineuses pour les fixtures, cette technique risque fort de ne faire que déplacer le problème .... Niveau volume on parle de combien de fixtures de test à peu près ?

[erictomcat]

plusieurs tables ayant chacune plus de 10 000 lignes, ça le fera pas

[Michel Rotta]

Tu as vraiment besoin de tables de plus de 10.000 lignes pour des tests unitaires ?

[erictomcat]

j'ai beaucoup de table avec beaucoup de relations entre elle, je trouve plus simple de remonter ma table de prod à un instant D que d'essayer de monter des fixtures plutot complexes

[Michel Rotta]

Pour des tests unitaires tu n'as pas nécessairement besoin de peupler toutes les tables tu peux te limiter aux tables qui font partie directement ou indirectement du tests, les autres peuvent rester vide.

De plus un test doit être reproductible ce qui n'est pas nécessairement le cas avec une copie de la base de production.

C'est toi le maitre de ton appli, à toi de voir...