Chargement des connections d'un Node

[benjamindulau]

Je reprend ici la discussion que nous avions avec @armetiz concernant le chargement des différentes connections d'un node.

Ceci pose un problème au niveau du mapping, car lors d'une demande des connections pour un Node auprès du ConnectionManager, la persistance ne sait pas quel type d'objet il doit "requêter".

[benjamindulau]

@armetiz je met ça ici pour pas perdre mes idées.

Que penserais-tu de maintenir une correspondance entre Nodes/Classes.
Tu disais qu'un node a une valeur, ce qui m'a donné cette idée.

Un Node peut implémenter une méthode getNodeType ou getNodeName (ou autre nom), qui retournerait une simple chaine unique identifiant le type de node.

De cette manière nous pourrions optimiser la méthode getConnectionsFrom du manager, et changer la signature en:
public function getConnectionsFor(NodeInterface $node, array $nodeTypes);

Ce qui permettrait au développeur de ne charger que ce dont il a besoin.

Exemple:

Un utilisateur peut follow d'autres utilisateurs, mais aussi des tags.
J'ai donc deux types de nodes: user et tag.

Si je sais reconnaitre ces nodes, je suis capable de ne charger que les connections vers les nodes qui m'intéressent.

Et en maintenant ces nodes dans la config, nous pourrions facilement savoir comment les charger dans un repository:

kitano_connection:
    nodes:
        user: { class: My\Entity\User }
        tag: { class: My\Entity\Tag }         

Ce qui constitue un registre que nous pouvons injecter dans les repositories.

Alors j'ai pas trop approfondie l'idée pour chercher les limitations. Je la pose là comme ça pour pas la paumer.

[armetiz]

Justement en parlant du chargement, j'ai peur que le chargement de plusieurs Connection et Node soit source de perte de perfomance.. A voir en fonction du nombre de type de Node possible...

[benjamindulau]

Ouais en devenant complexe, le Graph peut causer de grave problèmes de perfs :/
Il doit y avoir moyen d'optimiser ça avec des requêtes et un cache intelligents je suppose.

Tu peux décrire ton idée ici ? Celle dont tu m'as parlé sur IRC. Avec un exemple basique ?

[armetiz]

@benjamindulau : L'idée serai de reprendre le fonctionnement de Gedmo pour les traductions.

Une Facade pour communiquer avec l'application, qui prends en entrée des objets Connectable. Les objets Connectable sont des objets gérés par Doctrine, sinon on leve une exception.
Derrière la Facade, on récupère via l'ObjectManager & le ClassMetadata la clé primaire ainsi que le FQDN (Appelé ObjectClass par Gedmo). Ce traitement est à faire pour les deux objets Connectés : Source & Destination.
On définit le model via Model\Connection : sourceForgeinKey, sourceObjectClass, destinationForeignKey et destinationObjectClass.

Afin de simplifier l'utilisation de la Facade (dixit ConnectionManager) par l'application, on peux utiliser un DTO\Connection qui contient les objets Entity ou Document dans les propriétés DTO\Connection::source & DTO\Connection::destination.
De fait, l'application ne communique avec le ConnectionManager uniquement via DTO\Connection & des objets métiers.
Au niveau interne du ConnectionBundle, on traite avec Model\Connection & des données brutes.

A noter que pour réaliser les récupérations d'objets métiers. Comme nous avons les ObjectClass (FQDN des Entity / Document), il est simple de récupérer les EntityRepository/DocumentRepository et donc nos Entity / Document.

Au niveau performance,
Cela risque d'être peu pertinent.. A voir comment on peux optimiser la chose...

On rappel que ce Bundle n'a pas la vocation de remplacer les graphes performants, mais a pour objectif de pouvoir apporter la notion de "Connection" entre objet à tout projet sans devoir approcher des solutions comme Neo4J

[choomz]

Je reprend la conversation suite aux derniers commits. Le chargement des nodes via la config symfony est il toujours d'actualité ?

La création de la connection passe actuellement par ConnectionManager::create() puis connect().

Quel est donc le scénario d'utilisation? Comment transmettons nous nos NodeInterface au manager ?

[armetiz]

Le manager sera disponible via le Container.

Du coups,
J'avais en tête quelque chose de ce type :

$manager = $this->getContainer()->get("kitano.connection.manager");
$manager->create($userA, $bookB); //Create a new connection. No need to call $manager->connect(), this is done internally.

$manager->getConnections($bookB);

PS : J'ai conservé l'interface NodeInterface. Elle simplifie l'écriture des prototypes mais pourra être retirer par la suite si besoin.

[choomz]

Oui effectivement, c'est la solution que j'avais en tete à la vue du modèle et des interfaces.

Par contre au niveau du registre proposé par Benjamin, on fait quoi ?

[armetiz]

Quand tu parles de Registre, tu parles d'un système de cache ?
Car dans ce cas là on va mettre ca en interne et ca rejoindra l'issue #8

[choomz]

Non je parlais du 2eme com de Benjamin sur cette issue.

[armetiz]

Ouverture d'une Issue concernant la gestion du cache : #18