PRQL : un langage de requête relationnel en pipeline

 (github.com/PRQL)
4 points par GN⁺ 2023-07-27 | 1 commentaires | Partager sur WhatsApp
  • PRQL est un langage moderne pour transformer les données, visant à devenir une alternative à SQL qui soit, comme SQL, facile à lire, explicite et déclarative
  • Les requêtes sont composées comme un pipeline logique où chaque étape de transformation reprend le résultat précédent, avec prise en charge d’abstractions comme les variables et les fonctions
  • PRQL est compilé en SQL afin de pouvoir être utilisé avec toute base de données qui utilise SQL
  • Les exemples du langage utilisent des transformations comme from, filter, derive, group, aggregate, sort, take, et filter remplace les rôles de WHERE et HAVING en SQL
  • Parmi les fonctionnalités de syntaxe figurent une notation claire des dates, coalesce, des variables référençant d’autres variables, des F-strings proches de Python, des S-strings utilisant SQL comme échappatoire, une notation pour le tri décroissant et des expressions de plage
  • Sont proposés le PRQL Playground pour expérimenter dans le navigateur, le PRQL Book comme documentation du langage, et prql-lang.org avec comparaisons SQL et exemples
  • En date de juin 2026, PRQL peut être utilisé via des intégrations prises en charge ou des bindings de langage pris en charge, mais il reste certains bugs et des fonctionnalités manquantes, et le périmètre prêt pour un déploiement auprès d’équipes non techniques reste limité à des requêtes assez simples
  • Les priorités de développement portent sur un nouveau resolver, la correction des bugs prioritaires, la réduction des écarts fonctionnels restants pour couvrir la plupart des requêtes SQL standard, ainsi que l’ajout d’un support expérimental des modules et des projets multi-fichiers
  • Les points d’intégration incluent une extension VS Code, l’intégration Jupyter, l’intégration QStudio, le Jupyter magic, la documentation pyprql Docs et prqlc-js
  • Le dépôt est composé du compilateur prqlc, écrit en Rust, et de l’espace de contenu web web ; prqlc compile PRQL en SQL et inclut la CLI ainsi que plusieurs bindings de langage

À lire aussi

1 commentaires

 
GN⁺ 2023-07-27
Avis de Hacker News

  • Les exemples du site web https://prql-lang.org/ semblent être le plus grand atout de PRQL, en particulier parce que le SQL généré est propre et intuitif, comme s’il avait été écrit à la main.
    Il y a 10 à 15 ans, on créait de nouvelles bases de données comme Mongo, Riak ou Influx et on essayait de convaincre les développeurs d’applications de les utiliser dans de nouveaux projets ; aujourd’hui, avec EdgeDB, TimescaleDB ou PRQL, on voit davantage d’options conservatrices consistant à ajouter des add-ons ou des préprocesseurs de requêtes à Postgres, ce qui les rend bien plus faciles à adopter.
    Le schéma et les migrations côté Edge sont aussi intéressants, mais la syntaxe de PRQL est plus intuitive. Comme le code applicatif contient déjà beaucoup de pipelines de transformation de données — chaînes map/filter de TypeScript, itérateurs Rust, enumerables Ruby, streams Java, LINQ .NET, Rx dans plusieurs langages — le concept est très familier. Le fait de pouvoir générer du bon SQL avec PRQL, le sauvegarder, le vérifier plus tard, examiner le plan d’exécution et ajouter des index là où c’est nécessaire est excellent.

    • Ça a l’air plutôt bien, mais ça ne semble différer de SQL que par des détails infimes. Si Ruby était « une syntaxe plus conviviale qui se transpile en Python », j’aurais l’impression qu’on utiliserait simplement celui qu’on a appris en premier, sans forcément apprendre l’autre.
      Les exemples rendent SQL artificiellement plus verbeux. from employees / select {id, first_name, age} / sort age / take 10 paraît mieux qu’un SELECT ... FROM ... ORDER BY ... LIMIT ... réparti sur beaucoup de lignes, mais en vrai on peut aussi écrire du SQL comme select id, first_name, age from employees order by age limit 10 ; à part l’absence d’accolades et la différence entre order by et sort, on est presque à un ou deux caractères près.
    • Je ne comprends pas bien. Les exemples me paraissent beaucoup moins lisibles que SQL, et je ne vois pas pourquoi il faudrait utiliser ça.
      Le fait de pouvoir changer l’ordre des sections d’une requête est bien quelque chose dont tout le monde se plaint à propos de SQL, mais en échange on obtient plusieurs types de parenthèses, des deux-points et d’autres éléments de syntaxe qui semblent ajoutés sans raison, et ça ne paraît pas vraiment faire quelque chose que SQL ne sait déjà pas faire. Je me demande quel est son argument de séduction.

  • Nous avons récemment fusionné la prise en charge de PRQL dans ClickHouse : https://github.com/ClickHouse/ClickHouse/pull/50686
    Pour l’instant, c’est encore assez expérimental, et il n’est pas certain que ce soit réellement utilisable ou utile. Il y a aussi quelques inquiétudes liées à Rust : https://github.com/ClickHouse/ClickHouse/issues/52053#issuecomment-1643805521

    • Sympa. Je me demande si cela signifie que ce sera aussi utilisable avec clickhouse-local.

  • J’aimerais que PRQL grandisse fortement et devienne un langage pris en charge en première classe par Postgres. L’algèbre relationnelle est belle, mais SQL est une conception initiale bancale qui aurait dû être remplacée il y a des décennies.
    Même Codd n’était pas satisfait de SQL. Ce qu’il a inventé est remarquable, mais depuis, nous avons beaucoup appris sur la conception des langages de programmation.

    • Les gens associent souvent algèbre relationnelle et SQL, probablement parce qu’ils les ont appris ensemble. Mais SQL est un très mauvais langage relationnel, et il s’écarte du concept fondamental selon lequel une relation est un ensemble non ordonné, notamment en le brisant avec ORDER BY.
      Ce problème apparaît par exemple lorsqu’on encapsule dans une sous-requête et que l’ordre de la relation disparaît, ce qui est assez inattendu. Le modèle de données de PRQL ressemble beaucoup au modèle relationnel ; la grande différence est que les relations y sont définies comme des tableaux de tuples, donc avec un ordre. J’espère que PRQL sera connu comme un « langage relationnel Mk II ».
    • Ce n’est pas exactement ce que vous vouliez, mais DuckDB dispose à la fois d’une extension PRQL [1] et d’une extension Postgres [2], donc il devrait être possible d’y interroger une base de données Postgres en PRQL.
      Il existe aussi un plugin DBeaver [3] ; il a encore besoin de meilleure documentation et d’une simplification de l’usage, mais il pourrait lui aussi permettre d’interroger Postgres en PRQL. Enfin, avec pyprql [4], on peut interroger Postgres depuis un Jupyter notebook.
      [1]: https://github.com/ywelsch/duckdb-prql
      [2]: https://duckdb.org/docs/extensions/postgres_scanner.html
      [3]: https://github.com/PRQL/prql/issues/1643
      [4]: https://github.com/PRQL/pyprql
      À noter que je contribue à PRQL.
    • L’algèbre relationnelle reste excellente. Ce qui a transformé cette belle idée en un incroyable bazar, c’est SQL.
    • J’ai appris SQL pour la première fois quand j’étais ado, il y a 20 ans, et je me souviens avoir trouvé à l’époque que le langage était étrange et donnait littéralement l’impression d’être à l’envers.
      À ce moment-là, je pensais que c’était parce que je n’en savais pas assez pour comprendre pourquoi il devait en être ainsi, mais je sais maintenant qu’il n’y a pas de raison. SQL est devenu comme une langue naturelle : même si ça n’a pas de sens, on ne peut pas le contester, il faut juste le parler. Mais SQL n’est pas une langue naturelle, et on peut faire mieux.
    • Je n’ai jamais aimé le fait de choisir ce qu’on veut récupérer avant de choisir la source. La forme syntaxique ici est beaucoup plus intuitive.

  • Si le principal reproche fait à SQL est qu’on ne peut pas changer l’ordre de SELECT, FROM, WHERE, alors pour un langage conçu dans les années 70, il s’en sort plutôt bien.
    À l’inverse, PRQL semble avoir beaucoup de bruit syntaxique arbitraire. Je ne vois pas pourquoi je devrais préférer join side:left p=positions (p.id==employees.employee_id) à LEFT JOIN positions AS p ON p.id = employees.employee_id

    • Le vrai problème de SQL, c’est qu’il enferme dans une façon d’écrire très rigide, qui ne correspond pas bien au flux de pensée que j’ai en tête.
      Une approche comme PRQL, où chaque étape de haut en bas est une transformation de l’étape précédente, a beaucoup plus de sens. SQL nécessite un manuel de référence, alors que PRQL donne l’impression d’écrire directement ce que l’on veut que la requête fasse. Cela dit, la syntaxe des joins de PRQL est très mauvaise ; il aurait fallu conserver des mots-clés explicites du type left join, et mieux concevoir les alias ainsi que les raccourcis pour les colonnes de jointure
    • Les vrais reproches que j’avais envers SQL étaient au nombre de deux ; pour le reste, c’était plutôt correct.
      Premièrement, on ne peut pas utiliser plus loin, dans le même select, une colonne sélectionnée précédemment. On ne peut pas écrire gnarly_calculation AS some_value puis some_value * 2 AS some_value_doubled ; il faut envelopper ça dans une sous-requête. Deuxièmement, on ne peut pas désigner toutes les colonnes sauf certaines. Quand on doit remonter un calcul intermédiaire depuis une sous-requête mais qu’il n’est pas nécessaire dans la sortie finale, on ne peut pas dire quelque chose comme * EXCEPT some_value ; il faut lister toutes les colonnes de sortie voulues
    • Peut-être parce que je suis habitué à R et au paradigme tidyverse, mais dans l’ensemble ce paradigme et cette syntaxe me semblent assez lisibles.
      L’exemple choisi est peut-être un cas où les parenthèses et les virgules aident beaucoup, mais dans le contexte global du langage ce n’est pas si mauvais. : est utilisé de façon cohérente comme des arguments nommés, et = semble servir aux alias
    • C’est parce que le type de jointure devient désormais un argument de l’opération join, et que le premier mot de l’instruction est join, ce qui rend plus clair ce qu’est l’opération réelle.
      Même avec un exemple classique d’appel de fonction, foo(bar) est mieux que « bar to foo() »
    • Le problème de SQL est le même que celui des déclarations de variables à la C. Quand on lit le code à voix haute, cela paraît un peu mieux que les alternatives, mais en pratique cela crée des problèmes de lisibilité et d’analyse/traitement

  • PRQL 0.9 vient justement de sortir il y a quelques heures, donc le timing est bon. Les notes de version sont ici : https://github.com/PRQL/prql/releases/tag/0.9.0
    Il y a un assez gros changement incompatible : la syntaxe des tuples passe de [] à {}. Au début, ils ressemblaient à des listes, mais avec le temps on s’est rendu compte qu’il s’agissait en réalité de tuples. Comme l’indiquent les notes de version, libérer [] permettra bientôt de commencer à prendre en charge les tableaux. Pour info, je suis contributeur PRQL

  • Une limite de PRQL, par conception, est qu’il ne prend en charge que SELECT. Pour insérer/modifier/supprimer des données, il faut revenir à SQL.
    Le data scientist de l’équipe peut fournir des requêtes en PRQL, mais pour les intégrer dans un vrai pipeline de données, il faut les traduire en SQL. Ce serait bien de prendre en charge au moins une fonctionnalité limitée, comme l’insertion dans une nouvelle table temporaire. Par exemple sous une forme comme from tracks / filter artist == "Bob Marley" / save bob_marley_tmp

    • Je ne vois pas de raison pour laquelle PRQL ne pourrait pas prendre en charge les modifications de données. Il suffirait d’avoir des opérateurs insert/update/delete qui doivent venir en fin de pipeline, et qui prennent le nom de la table en argument.
      Un SQL comme UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' pourrait s’écrire en PRQL quelque chose comme from counters / filter startswith(name, 'prefix.') / derive { new_value = value + 1 } / select { name, new_value } / update counters
    • Oui, c’est là que j’ai perdu tout intérêt

  • L’article incontournable ici : “I don't want to learn your garbage query language” [1]
    [1] https://erikbern.com/2018/08/30/i-dont-want-to-learn-your-garbage-query-language.html

    • J’aime beaucoup cet article, et il est aussi lié depuis le site de PRQL.
      L’objectif de PRQL est de devenir un excellent langage sur lequel il soit facile d’intégrer et de construire. Nous ne voulons pas créer N langages pour N bases de données. PRQL sera toujours open source et ne créera pas de produit commercial ; je pense donc que c’est beaucoup plus réaliste qu’un langage propre à chaque base de données ou à chaque produit. Je suis développeur PRQL
    • La meilleure réfutation : https://www.scattered-thoughts.net/writing/against-sql/

  • Ancien Show HN : https://news.ycombinator.com/item?id=31897430
    « Show HN: PRQL 0.2 – a better SQL » a été publié le 27 juin 2022 par maximilianroos et a reçu 378 points et 161 commentaires.
    Le billet original où la proposition avait été faite : https://news.ycombinator.com/item?id=30060784
    « PRQL – A proposal for a better SQL » a été publié le 24 janvier 2022 par maximilianroos et a reçu 650 points et 295 commentaires

  • Cela me fait penser au KQL de Microsoft : https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

    • KQL est excellent, et il me manque chaque fois que j’utilise SQL
    • C’est le seul plaisir que j’éprouve en utilisant Azure

  • La syntaxe n’est pas si importante ; ce qui compte, c’est ce que fait l’optimiseur
    Aujourd’hui, beaucoup de problèmes de SQL ressemblent à un vieux bagage hérité. Comme les anciens moteurs géraient mal les syntaxes modernes, beaucoup de gens ont été conditionnés à écrire des requêtes difficiles à lire, complexes et profondément imbriquées. Par exemple, les expressions de table communes (CTE) étaient immédiatement matérialisées, ce qui a entraîné la prolifération d’un ancien style du genre SELECT FROM (SELECT FROM (SELECT FROM A JOIN (SELECT ) B ON A.x=B.x)))
    Grâce aux améliorations du traitement des CTE par les moteurs, il devient de plus en plus facile d’écrire des requêtes compréhensibles et composables comme WITH A AS (...), WITH B AS (...), WITH C AS (SELECT y FROM A) SELECT result FROM C WHERE .... Avec des fonctionnalités comme les fonctions de fenêtrage modernes, SELECT * EXCEPT et des variantes plus complexes telles que TOP X FOLLOWING, SQL peut devenir plus simple
    Dans ce contexte, je ne pense pas que de petites améliorations apportées par une forme syntaxique différente comme PRQL offrent un grand bénéfice. On peut réécrire cela sous forme de pipeline d’apparence impérative, mais l’optimiseur peut aussi en éliminer une partie. Il est vrai qu’il y a des choses à améliorer dans SQL, mais je n’ai pas encore vu d’argument convaincant en faveur de différences purement apparentes ou syntaxiques