Problème de mapping (symfony 3.4)

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

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é…

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.

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.

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…

oui dsl j’ai fait un copier coller sans regarder

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…

Et si tu spécifies le nom de l’EntityManager à récupérer à chaque fois, ça ne passe pas ?

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.

Merci Jhon ca me rassure

Ymox, dans le code, dans les controllers, … ca fonctionne au poil.

par contre en ligne de commande, tout fonctionne, sauf le schema:update —em=nom_de_l_entity_manage par contre, si je supprime le schema public, aucun problème.

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

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

pas exactement non.

car il passe uniquement que l’entitymanager client001 et default (schemas public) mais pas l’EM client002, client003…

et je ne vois pas comment passer xdebug sur de la ligne de commande. je vais googueliser tout ca

merci

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é)

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 ;))

Je voulais en être sûr. Tu as aussi bien modifié l’équivalent de la ligne 20 pour chacun d’entre eux ?

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