Un jour un projet : Ting

La série Un jour Un projet continue avec aujourd’hui l’ouverture d’un de mes projets préférés : Ting.

ting_2

L’essence de Ting

Ting est un DataMapper en PHP, conçu pour fonctionner avec Mysql & PostgreSQL. Ses principales caractéristiques sont :

  • Peu d’overhead
  • Utilisation des fonctions mysqli / pg_ natives de PHP
  • Pour Mysql : Tire parti du driver mysqlnd pour récupérer de nombreuses informations lors d’une requête
  • Pas de format intermédiaire / d’abstraction : vous écrivez des requêtes natives
  • Support des masters / slaves
  • Support de cache de requêtes (actuellement seulement memcached, les autres drivers ne demandent qu’à être implémentés)
  • Support de l’hydratation partielle d’objets (je sélectionne ce dont j’ai besoin dans ma requête)
  • Bon taux de couverture par les tests unitaires (grâce au framework de test atoum)

Aujourd’hui nous ouvrons au public le projet ting. Seront ouverts sous peu les projets ting_bundle (intégration dans symfony) et ting_user_bundle (implémentation de FosUserBundle pour Ting).

A noter, j’ai bien précisé qu’il s’agissait d’un DataMapper et non d’un ORM. En effet, il s’agit d’un choix fort lié à la conception de ce produit. A mon sens, la complexité (et dont le surcoût) de ce type d’outil vient souvent de la couche relationnelle, dont on peut aisément se passer – si cela vous intéresse, les recherches « ORM anti-pattern » ou « ORM are evil » vous donneront plein de ressources passionnantes à ce sujet. En réalité, Ting vient combler le trou qu’il existait entre le « full ORM » – magie et overhead inclus – et le « full PDO » – huile de coude et duplication de code, en permettant de manipuler facilement des objets et en évitant un overhead trop important.

Cela nous permet surtout de respecter les critères de performances en vigueur chez nous, indispensables dans notre contexte de très forte charge – due à notre position de leader français sur internet.

C’est fiable ?

Oui, très.

La réponse est un peu facile et semble peu argumentée, cependant nous avons déjà certains produits qui l’utilisent en production. Par exemple Ting a été déployé sur L’internaute dictionnaire il y a plusieurs mois, ce qui doit déjà représenter quelques millions de requêtes exécutées.

La roadmap de Ting :

Il n’y a pas de dates pré-établies pour la sortie de nouvelles versions. Cependant le projet est aujourd’hui assez mature. La version actuelle est la 2.5.0 et nous travaillons actuellement à préparer la version 3.0 avec les nouvelles fonctionnalités suivantes:

  • Support de PHP 7 (quelques noms de classes désormais réservés nous posent problème)
  • Ajout d’un QueryBuilder (susceptible de modifier légèrement les interfaces)
  • Support d’un outil de migration de schéma externe (liquibase ou phinx, c’est à définir)

Cette roadmap n’est pas figée, cependant une version 2.6.0 sera peut-être publiée avant la sortie de la 3.0 qui devrait intervenir d’ici la fin de l’année.

J’en profite pour remercier spécialement Sylvain qui travaille avec moi depuis le début sur ce projet et qui fait vraiment un super boulot.

En savoir plus :

Vous aimerez aussi...

8 réponses

  1. Bonjour,

    J’avais assisté à votre conférence sur les perfs à la Symfony Live 2016, vous y présentiez rapidement Ting.
    Nous nous essayons depuis peu à l’utilisation de Ting au sein d’un nouveau projet en interne, l’idée de base est d’éviter le monstre Doctrine, mais d’avoir un outil plus light et d’éviter Active Record :).

    Nos tests actuels sont encourageants sur l’utilisation de Ting, mais nous avons 2 interrogations:
    1- Avez-vous sous la main des projets open-source utilisant Ting ? Nous ne trouvons que peu d’exemples en dehors de la doc.
    2- Nous nous interrogeons sur la difficulté de gérer des relations imbriquées (de plus d’un niveau). Par exemple, un « client » possède des « commandes » qui possèdent des « produits » qui possèdent des « attributs de produit ». Comment récupérer l’ensemble de cette hiérarchie en une seule requête (3 JOINS) avec Ting de façon élégante ? Devons-nous écrire nous-même l’hydrateur pour ce cas précis (nous avons alors peur de la somme de code nécessaire pour tout écrire) ou y a t-il une méthode plus générique ?

    Merci par avance pour votre réponse, et également pour votre travail 🙂

  2. Sylvain Robez-Masson dit :

    Bonjour Raphaël,

    1- Pour le moment seulement un projet https://github.com/afup/web ça viendra peut-être 😉
    2- Si tu es sous Ting 3.3 le nouveau hydrateur devrait correspondre à ton besoin, cf : http://tech.ccmbg.com/ting/doc/3.x/en/hydrator.html#l-hydrateur-d-aggregation

    Pour plus d’informations je suis disponible très souvent sur https://webchat.freenode.net/ sur le salon #symfony-fr avec le pseudonyme srm`

    • Bonjour et merci de votre réponse !

      Nous sommes bien dans la dernière version de Ting et avons jeté un oeil à l’HydratorAggregator, mais cela ne semble pas couvrir notre besoin car de notre compréhension cela permet de faciliter l’hydratation d’une unique relation one-to-many.
      Qu’en est-il des relations imbriquées, c’est à dire comme dans mon exemple un « client » possède des « commandes » qui possèdent des « produits » qui possèdent des « attributs de produit » ? L’HydratorAggregator peut-il vraiment facilement couvrir une hydratation « one-to-many-to-many-to-many… » ?
      C’est une question déterminante pour nous afin de savoir si Ting peut répondre à un « assez gros » projet dans lequel il existe des centaines de cas pour lequels nous devons hydrater des objets imbriqués.

      • Sylvain Robez-Masson dit :

        Bonjour,

        En effet tu as raison, l’HydratorAggregator ne peut pas à ce jour faire de l’aggrégation à plus de 1 niveau.
        Je me mets en tâche de le faire évoluer pour que ça soit le cas, mais du fait que je suis en vacances à la fin de la semaine, ça ne sera pas là avant un bon mois.

        Cependant si tu regardes le code de l’HydratorAggregator tu peux toi aussi plancher sur une aggrégation à plus de 1 niveau en faisant ton propre hydrator ça peut répondre à ton besoin.

        Si tu as besoin d’une telle aggrégation plus tôt, désolé du coup je ne vais pas pouvoir te le faire dans les temps 🙁

        • Merci encore de votre réponse,

          Nous avons effectivement pour l’instant utilisé nos propres Hydrator pour ce besoin, mais du coup nous craignions d’avoir à écrire trop de code par nous-mêmes. Il s’agit peut-être là de la limite intrinsèque de Ting face à un véritable ORM ? De votre point de vue, s’il devient possible de réaliser nativement des relations imbriquées avec Ting, qu’est ce qu’il le différenciera réellement d’un ORM ?

          • Sylvain Robez-Masson dit :

            Et bien, tout simplement car il ne s’agit que de la lecture et pas de l’écriture.
            Ting donne plus de code à écrire qu’un ORM ça c’est sûr. Pour une meilleure maitrise de ce qui est fait. L’hydrator aggregator à été créé pour répondre à un besoin simple et éviter une redondance de code. L’améliorer pour gérer tes cas rentrera dans le même cadre. La différence avec un ORM c’est que Ting ne sera toujours pas capable de gérer l’écriture automatique d’un objet et de toutes ses dépendances (ce que l’on ne fera jamais, car le dev ne contrôle pas bien toutes les requêtes qui sont faites), tout comme le fait que Ting ne permettra jamais de faire une requête complexe automatiquement à ta place (une requête avec plusieurs jointures) car le dev maîtrise mal ce qui est fait.

            Voilà j’espère avoir bien répondu 🙂

          • Je comprends très bien et je suis d’accord en grande partie sur la philosophie de Ting (je n’aime pas non plus la magie dans les ORMs :).
            De notre côté, il nous reste à peser le pour et le contre: écrire des dixaines d’hydrateurs personnalisés, attendre que Ting soit doté d’un mécanisme d’hydratation sur plusieurs niveaux, … ou passer à Doctrine qui semble un candidat lourd dans les 2 sens du terme :).

            Le choix d’un système de mapping des enregistrements d’une BDR vers des objets PHP n’est pas anodin, et il n’est pas facile de savoir à l’avance si Ting peut être adapté à de gros projets (style +100000 lignes de code, +500 tables, +100 relations parfois complexes)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *