Problème de mapping (symfony 3.4)

Le problème exposé dans ce sujet a été résolu.

Bonjour,

Je gère un gros projet pour plus de 120 clients sur symfony 3.4 et une base de donnée postresql.

chaque client a son schema (environ 500go de données par client)

Le projet est composé de 2 Bundles

  • l’appBundle est le core du projet, il gère les données des 122 clients (les posts, les stats… )
  • ParametreBundle gère les caractéristiques communes aux 120 clients (les profils, … )

Afin que doctrine gère correctement, j’ai surchargé son driver pgsql comme proposé sur stackoverflow

Et ca fonctionne au poil (sur plusieurs de mes projets)

Mon config.yml ressemble a ca:

doctrine:
    dbal:
        default_connection : default
        connections:
            default:
                driver:   pdo_pgsql
                driver_class: AppBundle\Doctrine\DBAL\Driver\PDOPgSql\Driver
                options:
                    search_path: public
                host:     "%database_host%"
                port:     "%database_port%"
                dbname:   "%database_name%"
                user:     "%database_user%"
                password: "%database_password%"
                charset:  UTF8
            client001:
                driver:   pdo_pgsql
                driver_class: AppBundle\Doctrine\DBAL\Driver\PDOPgSql\Driver
                options:
                    search_path: client001
                host:     "%database_host%"
                port:     "%database_port%"
                dbname:   "%database_name%"
                user:     "%database_user%"
                password: "%database_password%"
                charset: UTF8
    orm:
        default_entity_manager: default
        entity_managers:
            default:
                connection: default
                mappings:
                    ParametreBundle: ~
                naming_strategy: doctrine.orm.naming_strategy.underscore
            client001:
                connection: client001
                mappings:
                    AppBundle: ~
                naming_strategy: doctrine.orm.naming_strategy.underscore
        auto_generate_proxy_classes: '%kernel.debug%'
php bin/console do:sc:cr --em=default


php bin/console do:sc:cr --em=client001


php bin/console do:sc:up --force --em=default

fonctionnent parfaitement.

par contre

php bin/console do:sc:up --force --em=client001

plante

SQLSTATE[42P01]: Undefined table: 7 ERREUR:  la relation « libelle_c_f_id_seq » n'existe pas
  LINE 1: SELECT min_value, increment_by FROM "libelle_c_f_id_seq"
                                              ^

In PDOConnection.php line 106:
  SQLSTATE[42P01]: Undefined table: 7 ERREUR:  la relation « libelle_c_f_id_seq » n'existe pas
  LINE 1: SELECT min_value, increment_by FROM "libelle_c_f_id_seq"

sachant que libelleCF est une entity de ParametreBundle et pas d’AppBundle…

Je sèche complètement…

edit: j’avance, lorsque je drop le schema public, ca marche très bien. c’est comme si apres avoir mis à jour l’entitymanager client001 il voulait aussi passer le default

+0 -0

Salut !

Je ne me souviens plus, mais est-ce que tes entités pour chaque client sont dans des espaces de noms spécifiques à ces clients ?

Je sais que la récupération de l’EntityManager correct est soit implicite parce que l’entité est liée à un EM précis, soit explicite quand on appelle $this->getDoctrine()->getEntityManager('client001')… Or, j’imagine que les entités "communes" sont liées à tous les EMs, et Doctrine prend le premier qui soit trouvé…

+0 -0

Salut Ymox et merci pour ta réponse,

par contre, j’ai du mal a te suivre…

$this->getDoctrine()->getEntityManager(’client001’) va cherche l’EM client001

$this->getDoctrine()->getEntityManager() va chercher default (puisque c’est l’EM par défaut définit dans config.yml

il n’y a de liaison entre les entity de AppBundle et ParametreBunde si c’est ta question, pas de namespace a indiquer dans les commentaires doctrine des entity.

$this->getDoctrine()->getEntityManager() va chercher default (puisque c’est l’EM par défaut définit dans config.yml

Leeroy Jenkins

Mmm non, je ne suis pas certain que ce soit aussi simple que ça.

Parce que j’imagine qu’un peu partout, tu utilises simplement $this->getDoctrine()->getManager()->getRepository(UneClass::class), et que ça fonctionne dans la plupart des cas. Mais ça implique que Doctrine se débrouille pour savoir quel EntityManager est lié à la classe UneClass. Seulement, quand une classe particulière existe dans tous les EntityManagers, Doctrine ne peut pas savoir lequel doit être pris, et donc prend default qui est le premier pour lequel elle voit la classe…

Bref, pour les entités qui sont vraiment communes, il faut probablement spécifier le nom de l’EntityManager à utiliser, sans quoi je pense que ce sera default au lieu de celui du client.

Au passage, ma faute : j’ai mis getEntityManager() qui n’existe plus depuis Symfony 2.1, vu que c’est bien getManager(…).

Edit

En fait, je ne suis pas sûr de bien comprendre comment ça fonctionne, ces histoires d’entités et de managers spécifiques par clients du fait de la connexion…

+0 -0

oui dsl j’ai fait un copier coller sans regarder :D

j’utilise

$this->getDoctrine()->getManager(’client001’)->getRepository("AppBundle:monEntity");
pour mes entity AppBundle

et $this->getDoctrine()->getManager()->getRepository("ParametreBundle:monEntity");
Pour celle de parametreBundle

Je n’ai aucun double de nom dans les nom d’entity dans aucun bundle et il n’y a aucune entitée qui soient communes aux 2 bundles.

Si ut ne connais pas, c’est rudement pratique, il va falloir d’ailleurs que je regarde sur symfony 4 et l’abandon des bundles, ca risque de me compliquer la tache…

il va falloir d’ailleurs que je regarde sur symfony 4 et l’abandon des bundles, ca risque de me compliquer la tache…

Leeroy Jenkins

Tu peux toujours organiser tes dossiers comme bon te semble. Les bonnes pratiques de SF4 préconisent l’abandon des bundles dans le dossier src ; libre à toi de faire autrement. ;)

+0 -0

En fait, c’est comme si le paramètre --em n’était pas pris en compte, si j’ai (finalement  :honte: ) bien compris ?

Est-ce que tu as essayé de faire du debugging pas à pas avec xdebug pour voir à quel moment cette valeur était perdue ?

+0 -0

Je m’en voudrais d’enfoncer une porte ouverte, mais tu nous as montré un fichier de configuration avec uniquement deux EM / deux connexions (et étrangement, ce sont les deux que tu arrives à faire reconnaître en CLI), j’imagine que c’était uniquement pour exemple et que tu as bien déclaré toutes les connexions et EMs pour les autres clients ?

P.S. : je vois que tu as mis "synfony" dans le titre. Outre la coquille, je te propose d’utiliser les tags à la place (symfony et symfony 3.4, cf. la fin de ce message et ce qui y est lié)

+0 -0

ok, je vais corriger le titre et le tag, dsl, j’ai de gros doigts :)

Je n’ai pas mis le fichier config complet, il y a plus de 100 entitymanager soit environ 1800 lignes de configuration.

Tous les EM sont répertoriés avec des noms du type client001, client002 , client003, … Pour être le plus clair, 001 correspondant au département 1, l’Ain, 002 => département 2 l’Aisne, … et il y a des infrastructures plus riche selon les départements…

et je n’ai pas mis 200 ligne de config, parce que je ne pense pas que cela soit utile et parce que je suis obligé de modifier manuellement pour cacher certaines informations (tel que le nom de mon client ;))

oui bien sur.

d’ailleurs le site web fonctionne parfaitement, chaque client a bien ses informations, … seul la mise à jour via CLI ne fonctionne pas.

bref, j’ai fait une command perso, qui renomme le schema public et met a jour les différent entity manager, puis renomme le schema public précédement modifié et ca marche très bien…

parfois, on bricole, parfois on fait propre :D

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte