Ting : Datamapper

[srm]

Un cache n'est pas reset à chaque page, enfin dans le cas les plus courant, bien au contraire.
Par exemple chez nous le cache reste toujours là, il est écrasé par les nouvelles données quand elles sont modifiées.

Alors un autre exemple :

SELECT city.name, city.zipcode, country.id

FROM city

INNER JOIN country ON (country.id = city.country_id)

Puis

SELECT country.name, city.zipcode, country.id

FROM city

INNER JOIN country ON (country.id = city.country_id)

Comment tu fais pour savoir que name est pour City ou Country ?
Mais ça c'est qu'une des problématiques.
Ting c'est comme une grosse librairie, puis tu peux tout faire sans et ça demandera beaucoup plus de code, mais c'est faisable.
La preuve Ting a été codé en PHP, donc tu peux recoder l'équivalent en PHP.

Ting gère par exemple aussi l'UnitOfWork.
Si tu fais :

$city = new City();

$city->setName("Luxiol");

$unitOfWork->pushSave($city);

$unitOfWork->process();

Tu vas me dire que tu peux faire pareil en faisant une requête update avec un getName().
Oui mais non, parce que Ting dans ce cas par exemple :

$city = new City();

$city->setName("Luxiol");

$unitOfWork->pushSave($city);

$unitOfWork->process();



$city->setName("Paris");

$city->setName("Luxiol");

$unitOfWork->pushSave($city);

$unitOfWork->process();

Ne vas faire qu'une requête en base, car il voit que l'objet au final n'a pas changé entre sa valeur en base et ce que tu lui demande de sauvegarder. Il va enregistrer en base que ce qui a réellement changé, pas la totalité de l'objet.

[srm]

De même si tu fais ça :

$query = $this->getQuery('SELECT id, name FROM user WHERE name = :name');

$query->setParams(['name' => 'Sylvain']);

$collection = $query->query();

foreach ($collection as $data) {

    print_r($data);

}

Et que la requête te retourne 10000 utilisateurs, tu n'as 10000 objets utilisateurs en mémoire que si tu parcours toute la collection.
Les objets sont construits à la volée durant l'itération pour une occupation mémoire minimale.

[Xenos]

Un cache n'est pas reset à chaque page, enfin dans le cas les plus courant, bien au contraire.

Okay, là, ça devient utile oui. Comment Ting assure-t-il cette persistance?
Après, dans le cas d'un jeuweb, faut tester car j'ai été surpris de voir que chez OVH, la lecture d'un fichier du FTP est plus lente qu'une requête de BDD O.o Je suppose qu'ils ont eux aussi un genre de "cache" entre les machines (cache en RAM ou assimilé).

Comment tu fais pour savoir que name est pour City ou Country ?

Comment Ting le sait ?

Ne vas faire qu'une requête en base, car il voit que l'objet au final n'a pas changé entre sa valeur en base et ce que tu lui demande de sauvegarder.

Je suis partagé pour celle-là, car le nom de l'objet a eu le parcours suivant: Luxiol (c'est pas loin ça ^^) - Paris - Luxiol. Si on est dans une transaction, okay, les autres utilisateurs en BDD n'y verront que du feu, mais on perd une notion d'historique (on ne voit pas que la valeur est passée par "Paris"). Si l'historisation est faite par la BDD (type TRIGGER sur UPDATE de la table, qui sauve la valeur courante dans une table d'histo), alors le trigger ne sera pas déclanché.
J'ai rien à redire sur le fonctionnement, mais perso, je n'aurai pas choisi celui-là (je le trouve contre-intuitif).


L'occupation mémoire, okay, pourquoi pas, mais si tu demandes 10.000 objets à la BDD pour ne pas les utiliser, c'est tordu... D'autant que cela surcharge le réseau (au taff, c'est lui qui coince plutôt que la mémoire PHP).

[srm]

Le cache est fait via memcache uniquement actuellement.
Ting se sert pour Mysqli d'une analyse des métadonnées fournis par le Driver Mysqli (que PDO ne donne pas d'ailleurs), ou pour Postgresql d'un parsing avancé de la requête sql.

Si ta modélisation se repose sur le fait que durant le même process tu veux persister en bdd la destination (qui était à l'origine Luxiol) Paris, puis remettre à Luxiol et te baser sur des triggers pour faire ça, c'est une très mauvaise modélisation. Tu imposes à ton système deux écritures de données alors que ça ne servait à rien. D'autant plus que si tu veux un historique à ce sujet, c'est carrément dans une autre table que tu stockeras l'information.

Tu peux avoir un cas ou tu demandes 10000 objets, mais ou dès que tu as travaillé avec un, tu l'unset de la mémoire ce qui fait que tu n'as jamais plus d'un objet en cours sur lequel tu travailles. Voilà pas de consommation mémoire et tu peux même faire ça avec 1 million d'objet

[Xenos]

Okay, je ne connaissais pas l'anayseur des metadata de MySQLi. Ca te retourne quoi (perso, je dirai "country.name" vs "city.name", mais dans des cas autres qu'un INNER JOIN, genre subquery)?


Mouais, je vais prendre l'exemple d'un personnage qui se déplace sur les cases d'un map de jeu; le serveur reçoit la liste des cases par lesquelles il passe (liste calculée, par exemple, par un A* coté client). Je préfère envoyer chaque case à la BDD, qui l'enregistrera alors et activera le TRIGGER qui va sauver l'historique de déplacement dans une autre table (oui, faut 2 tables séparées, c'est sûr ^^), plutôt que de faire plus de code coté client pour faire ces mêmes traitements. Le SGBD se débrouillera tout seul pour limiter les écritures sur le disque. D'autant que si une case du trajet n'est pas autorisée, la BDD va refuser la suite des enregistrement et le personnage sera donc arrêté "au plus loin" sur ce chemin (plutôt que stoppé au début si c'était fait coté client).

Mais bon, c'est pas forcément une méthode objectivement défendable, c'est surtout dû au fait que je pense que la logique métier des données doit se trouver coté SGBD plutôt que dans le code client (cela devient d'autant plus vrai si on a plusieurs clients pour une même logique de BDD, par exemple un client web, un client lourd java et un client tablette, c'est le cas chez Alstom General Electric).


Il me semble que PDO permet le même genre de système pour l'optimisation mémoire (instanciation des objets à la volée, et le GC de PHP se charge de les supprimer s'ils ne sont plus référencés). Oui, si tu fais un fetchAll, PDO te crée un tableau avec tous les résultats dedans (donc lourd), mais un while (...->fetch()) aura le même effet que ton foreach.

---

$query = $this->getQuery('SELECT id, name FROM user WHERE name = :name');

$query->setParams(['name' => 'Sylvain']);

C'est pratique à l'usage, cette structure? Là, okay, c'est assez facile à gérer puisque $query est instanciée à la ligne du dessus, mais si jamais $query vient d'un paramètre de méthode, alors comment savoir le mapping à faire dans le setParams()?

[srm]

Dans le cas que tu cites dans tous les cas tu persistes ton objet à chaque changement pas juste à la fin, donc ça marche avec Ting.
Possible pour PDO et le fetch, mais faire de la composition d'objet il ne sait pas.

Tu dois pas avoir ce cas là, c'est une mauvaise pratique.

[Xenos]

Si tu considères que c'est une mauvaise pratique, alors ne scinde pas les deux lignes et propose plutôt un

$query = $this->getQuery('SELECT id, name FROM user WHERE name = :name', ['name' => 'Sylvain']);

Perso, mauvaise pratique, je dirai que non puisque si j'abstrais le ->getQuery() dans une factory, je tombe carrément dans un cas de décorrélation:

$query = $queryFactory->getUserInfosQuery();

$query->setParams(['name' => 'Sylvain']);

Or ce genre d'approche me semble parfaite pour permettre des gestions de droits aisées (par exemple, on peut avoir une factory pour le visiteur, une pour le joueur, une pour le modérateur et une pour l'administrateur, avec des filtrages différents). Sinon, tu le gèrerais comment, toi, le système de droits?

[srm]

Ca pourrait se faire le premier cas oui
Avec le QueryBuilder que l'on est en train de mettre en place pour Ting 3