Ting : Datamapper

[srm]

Et Ting gère aussi le cache des données

[niahoo]

Ok mais du coup pourquoi avoir ingnoré PDO ? Inutile, ou trop gourmand ?

[Xenos]

Le cache de données, je me méfie car cela voudrait dire que tu requête les mêmes objets en boucle (sinon, le cache ne sert pas à grand chose). Dans un code PHP, cela sent le codesmell.

Perso, utiliser un framework (même petit), c'est du travail en plus car de la maintenance en plus alors que la MaJ de PDO n'est pas à ma charge.


Les jointures deux fois sur le même objet, de base, j'évite (tout simplement car un SQL renvoie des données tabulaires, donc cela alourdit énormément le réseau). Le plus souvent, j'ai besoin d'un objet, je le récupère, et il va se compléter à la demande avec une liste d'autres objets.
Supposons que je veuille quand même le faire à toute force (mais bon, là encore, SQL n'est pas un langage adapté pour cela, c'est du XML/DOM qu'il faut là; d'ailleurs, renvoyer du XML, ce serait surement la piste vers laquelle j'irai), alors PDO me génèrerait la liste des Bean correspondant aux lignes de données (avec les données BeanObjet1+BeanObjet2), je passerai ce bean en paramètre à une FactoryObjet1, qui se chargerait d'instancier Objet1 ou de me renvoyer une l'instance Objet1 qu'elle a en mémoire (ou qu'une autre classe, peut-être statique, a; ce pourrait être la classe Objet1 justement).

Je mets donc la logique d'unicité hors de la logique de lecture de la BDD. Cela me permet de conserver l'unicité de l'objet que j'appelle $factoryObjet1->instanciateFromPdoBean(...) ou $factoryObjet1->instanciateFromId(...).

[srm]

Pour des raisons de performances, MySQLi est bien mieux.

Oui sur un site à x millions de requêtes ou les données changent 2 fois par jour, le cache est inutile tu penses ?
Mais bon manifestement tu ne sais pas du tout de quoi tu parles, je vais en rester là, je ne vais même pas prendre la peine de répondre à la suite de ton message.

[Xenos]

Apart from better performance [suivant comment on l'utilise], PDO has proper exception handling, a better object-oriented interface and supports binding of entire arrays. Now you have no reason not to use PDO.

( http://wooptoo.com/blog/pdo-vs-mysqli-pe...omparison/ )

While both PDO and MySQLi are quite fast, MySQLi performs insignificantly faster in benchmarks - ~2.5% for non-prepared statements, and ~6.5% for prepared ones.

Ultimately, PDO wins this battle with ease. With support for twelve different database drivers (eighteen different databases!) and named parameters, we can ignore the small performance loss, and get used to its API.

( http://code.tutsplus.com/tutorials/pdo-v...-net-24059 )

What you may want cached are the results returned from the same SQL query, [...] this is a feature of your DBMS (MySQL for instance), not PHP.

( http://stackoverflow.com/a/1884693/2342518 )


Ce cache est gardé d'une requête à l'autre? Comment Ting sait-il que les données de DB n'ont pas changé entre deux appels? Au pif?

Si j'ai besoin d'un cache, je me dirigerai plutôt vers l'une des extensions existantes (PEAR, PECL, ou mysqlnd_memcache). Sinon, si tu veux faire du cache, mieux faire 1 module dédié au cache (idéalement, une extension, histoire que ce soit transparent coté code PHP et pour des raisons de perfs) plutôt que de l'intégrer à un DataMapper.


PS: c'est tellement enrichissant quand nos échanges finissent par "j'te parle plus parce que moi je sais et toi pas mais je n'expliquerai rien"...

[srm]

Non mais quand déjà on parle de cache tu dis que c'est parce que c'est mal conçu que l'on a besoin de cache.
Qu'est ce que tu veux que je réponde à ça ? Que 99% des sites à fort trafic qui utilisent du cache (même sans doute 100%) sont mal conçu ? Allons réfléchis un peu à ce que tu dis.

Et de plus je vois pas ce que vient faire ton article sur PDO là, puisque tes questions soulevait l'intérêt de Ting pas du choix judicieux ou non de PDO.

C'est du cache géré par l'utilisateur, à lui d'invalider le cache quand il a changé, ou il expire auto au bout d'une durée X.

C'est intégré si on veut, c'est juste une glue entre Ting et un système de cache, d'ailleurs le système de cache de Ting va passer à la PSR-6 et une fois ça fait, on utilisera sans doute une librairie externe dès qu'une bonne existera.

Ting te permet d'éviter toutes les complexités que tu peux avoir à mapper ta base dans des objets.

Une requête comme ça :

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

FROM city

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

Tu fais comment pour la mapper dans tes objets ?
Ting le fait tout seul.

[Prélude]

Je rêve d'un Radio Prélude avec Xenos et SRM sur un sujet trollesque... Que du bonheur que ce serait

[srm]

Si c'était que du troll je pourrais comprendre, mais le truc c'est que c'est de l'incompétence mais qu'il ne s'en rend pas compte.
Et je peux avancer ça avec un argument simple, il ne connait pas la différence entre le pattern DataMapper et ActiveRecord, donc par conséquent il parle d'un sujet qu'il ne connait pas.

[Prélude]

Ah ouais, il me faut absolument cette émission ! Trop marrant que ce serait. Pour finir l'année en beauté.
Alors, on se la fait quand donc ?!

[Xenos]

PDO, je répondais à ça: "Pour des raisons de performances, MySQLi est bien mieux" et je faisais suite à mon premier message "je ne vois pas la différence avec PDO".

C'est intégré si on veut, c'est juste une glue entre Ting et un système de cache, d'ailleurs le système de cache de Ting va passer à la PSR-6 et une fois ça fait, on utilisera sans doute une librairie externe dès qu'une bonne existera.

Okay, ça me semble bien de séparer les 2.
Okay, l'utilisateur gère la validité du cache. C'est pas ce que je comprenais d'un "Ting gère aussi le cache des données", d'où ma demande de précision.


Si le cache est reset à chaque page, ben, oui, ça me semble mal barré niveau utilité. C'est le cas? Si oui, t'as un exemple d'application de ce cache?


Un SGBD relationnel type SQL renvoie un tableau de résultats, où chaque ligne est indépendante l'une de l'autre, donc vouloir mapper la jointure dans 2 objets différents, oui, pour moi cela ne fait pas sens de base (c'est un SGBD non-relationnel qu'on veut dans ce genre de cas... j'me répète).
Sinon, pour te répondre, je ferai comme dit: fetch PDO dans un Bean ($object->name, ->zipcode ->countryName; je passe sur le nom de colonne dupliqué), que je passe en paramètre à une factory ou au constructeur de mes classes. Je n'aime pas avoir de mapping dans mon code PHP décrivant ma structure de BDD.

---

Un radio Prélude SRM/Xenos, je veux bien si c'est pour en apprendre des choses, pas si c'est pour me faire traiter d'incompétent inconscient par un pédant adepte du mutisme. /->Ca, c'est du troll