 Salut tout le monde, moi c'est Stéphane. Aujourd'hui je vais vous parler un petit peu de Piton et Poserai. Je pense que tout le monde l'utilise un petit peu pour savoir comment interagir avec une base de données, pour l'utiliser, pour faire des sites web. Mais est-ce que vous êtes su à certains de pouvoir l'utiliser à 100% ? C'est-à-dire je vais vous montrer un peu quelque chose que d'habitude on ne connaît pas bien. Donc déjà pour me présenter, c'est STF. Ici on voit que j'ai fait une photo au Mont-Royal. D'ailleurs c'est Mont-Royal, parce que c'est super. Sinon, par ça, si on parle sur le P-degré, je suis membre de la PSF, de la PSF, c'est la Fondation Piton, tout le monde connaît, je pense. C'est marrant, il y avait un truc qui s'appelait le Python, c'était l'année dernière, etc. Sinon, il y avait aussi, je suis membre de le PS, le PS c'est l'Europe Python Society, ça organise l'Europe Python en Europe, membre de l'AFPY, donc il y a certains membres de l'AFPY, c'est l'association francophone de Piton, et à part ça, j'organise le Python Fossedem. Alors le Fossedem, c'est un petit événement, il y a 5000 personnes qui se joignent dans une université en Belgique. Il y a 5000 geeks qui s'amènent, et moi en fait je m'occupe de la Devroom Piton, ça fait 500 personnes, j'ai 10% de la populace, donc c'est cool. Sinon, vous avez les contacts, Matrixize, c'est FenerobaseWirtel.be, et en dessous, bel site web, donc c'est pas bien compliqué. Alors aujourd'hui, le petit agenda, puisqu'on va savoir de quoi on va parler, c'est quand même, avec Piton, on a principalement psychopégé 2, et on a d'autres petites libres, mais c'est celle-là qui m'intéresse. Après, je vais montrer un petit peu à l'ambic, donc c'est un outil de migration. On a PeeWeek, c'est un petit ORM assez basique qui fait 3000 lignes de code. On a Multicorn qui va vous montrer un petit peu ce que c'est que les FDW, donc les Foreng Data Wappers 2 de Postgre. On a PL Python qui vous permet d'étendre directement Postgre SQL avec du Piton, pur, sans vous casser la tête, sans faire croque, ce soit. SQL Chemique est le grand frère de PeeWeek, en gros c'est le Bazooka quand vous avez envie de flinguer quelqu'un, Piton, bien évidemment, et les poules de connexion, mais bon ça je pense que vous connaissez un petit peu, donc j'ai pas besoin de revenir là-dessus. Piton, ben voilà, on est un beau petit serpent. Alors, qu'est-ce que c'est ? C'est un petit langage de programmation, tout le monde connaît, je pense qu'il y en a quand même 50 ici qui l'utilisent, ou alors je me suis gouré de conf et je dois être chez Ruby. Sinon, c'est une syntaxe assez simple, visible. Dans les années 2000 en Belgique, on essayait d'apprendre ça à des gamins de 5 ans. Bon, j'ai un peu loupé là, parce que maintenant j'ai 35. C'est interprété, multi-platformes, petit page dynamique fort, multi-paradigmes et garbage collector. Alors, pause gré, qu'est-ce que c'est ? On va voir un peu l'historique. Historique, ben ça a été développé du côté de Berclay, waouh, c'est loin, récriture de Ingress. Alors, ça commence dans les années 85, 95, principalement, parce qu'avant il n'y avait pas de SQL, c'était assez lent. J'ai déjà vu d'une société qui devait travailler avec ça et c'est tout on sait, il se casse bien la tête. 97, 2013, 2014 et maintenant on est en 2015, donc c'est pause gré 9.5 qui va devoir sortir. Alors, tout le monde connaît pause gré, c'est une base de données qui prend le principe acide, qui respecte le SQL 2011, qui contient des data types, donc les chaînes de caractère, tout ce que vous voulez en fait. Il ne vous pas vous casser la tête, même du JSON. Transactionnel au niveau de la modification du schéma, donc vous faites un create table, vous faites un rollback, mais automatiquement la base de données, la table est virée. Pouvez l'étendre, donc si jamais vous n'utilisez pas pause gré de cette manière là, vous allez voir, multicompte, c'est un truc mais génial. D'ailleurs, on se demande à quoi ça sert au racle. Alors, comme table expression, ça c'est simplement pour les weaves, etc. C'est un truc qui est normalisé dans la norme SQL, qui est super intéressant. Pouvez faire un select, un update et un insert en même temps dans une seule raquette, d'habitude on en fait trois à la fois. Il y a le MVCC, c'est pour pouvoir gérer les différentes transactions en parallèle, et bien évidemment cross-platform. Il y a aussi la réplication, mais ce n'est pas le principe. On a les forêts data-wappers, donc ça, je vais venir par après. C'est une fonctionnalité qui vous permet par exemple de puits pause gré, discuter avec Twitter ou un flu RSS ou quoi que ce soit. Vous avez le langage procédureau, donc PL Python dans ce cas-ci, sinon on aurait parlé de PL Rubi, PLv8 et autres, mais ça ne nous intéresse pas. Et les autres points qui sont aussi tout intéressants, mais qui ne nous intéressent pas ici. Alors, les forêts data-wappers, qu'est-ce que c'est ? C'est la possibilité de pouvoir utiliser une source externe à pause gré, depuis pause gré. En gros, vous avez une base de données MySQL, une base de données Oracle, SQL Server, ce qui arrive souvent quand vous devez faire une intégration de pause gré SQL, vous devez reprendre ce qui existe déjà. Donc sans devoir vous amuser à faire des scripts d'extraction à port et autres, vous pouvez utiliser directement pause gré, utiliser une hybride qui s'appelle Multicom, qui est codé en Python avec un Bidding en C, Bidding en Python et qui est codé en C. Et à partir de là, vous pouvez interagir avec tous les systèmes qui existent. Donc moi ici dans les exemples qui sont donnés, c'est l'interaction avec Twitter, avec un Flux RSS, un Fichier C, c'est un XML, le file système, vous les listez les fichiers qui sont sur le système, il n'y a pas de problème. Ou regardez les procès existants. Alors, le PL, parce que j'en parle un petit peu, ça permet quoi d'étendre la base de données, de rajouter des fonctions stockées. Donc oui, certains sont cifs, d'autres ne le sont pas. Par exemple, le SQL, c'est très cif, le PL-PG SQL, ça l'est aussi. C'est limité à la base de données, il n'y a pas de problème. Par contre, tout ce qui est un cif, c'est le C. Le C, oui, vous pouvez étendre, rajouter, il y a des gens qui s'amusent à coder des trucs, des extensions au C ou faire des interactions au C, ça vaut la peine. PL Python, qui est un cif, j'expliquerai un peu plus loin pourquoi. PLv8, PL Perl, j'ai mis Perl parce qu'il faut bien que ça existe ce truc. Alors, on a DB API 2. Alors, qu'est-ce que c'est que ce machin ? En fait, on ne peut pas s'amuser à coder comme on veut avec les bases de données en Python. Il y a des gars qui sont amusés, dont Marc-André Lambert, qui est un mec super, et qui sont dit, on va faire une norme, un standard. Et à partir de là, ce standard-là va définir certaines choses. Donc, comme c'est un standard Python, il y a une PEP, qui est à 249, qui est intéressante à lire parce que je vous jure, il y en a beaucoup qui posaient questions sur Google comment interroger POSGRAE. Il lit la PEP et il aura tout compris. Alors, la PEP, qu'est-ce que c'est exactement ? C'est une API qui permet de gérer directement les connexions, les curseurs, etc. Donc, si on la lit, on comprend beaucoup de choses. Il y a deux concepts principaux, c'est-à-dire les connecteurs, donc les connexions et les curseurs. J'ai mis le petit lien, si vous ne me croyez pas, c'est bien là. Alors, la connexion, qu'est-ce que c'est ? Ben, c'est simplement, je me connecte, je ouvre une connexion, TCPIP en UNIX SOCET, ce que vous voulez, et je gère le start transaction, le commit et le rollback. C'est pas au niveau du curseur, mais assez au niveau de la connexion. Ne permet pas de gérer des requêtes SQL. En fait, c'est simplement, vous dites, j'ai une connexion vers le serveur et je travaille dessus. Ensuite, la connexion permet de faire plusieurs choses. Ben, le commit qu'on a déjà vu, le close pour fermer la connexion, le rollback, et le truc assez intéressant, première chose très intéressant, la connexion vers une base de données, et le curseur. Alors, le curseur, je l'ai mis entre crochet, parce qu'il y a un nom. C'est-à-dire, vous pouvez créer des curseurs qui sont au server-size. C'est-à-dire que lorsque vous allez interroger une base de données avec 10 millions de records, au lieu de faire un fetch-all qui va récupérer tout dans la mémoire du client, du process client, c'est au niveau du serveur. Donc, comme ça, vous évitez d'avoir une saturation de mémoire. Alors, des petits exemples avec la librairie posgrés, un exemple normal avec le DBA PI2, c'est simplement, vous importez votre driver et chaque driver doit respecter directement les différents callbacks qui sont spécifiés. Là, c'est un exemple. Je pense que vous les connaissez tous, il n'y a pas trop de problèmes. Sur les curseurs, on peut créer une connexion. Pardon, excusez-moi, une connexion, ça, c'est autre chose. Et, comme on dit, ici, c'est un petit exemple. Donc, je crée un curseur. Tout à l'heure, j'avais créé une connexion. J'exécute quelque chose et ça, je fais simplement une lecture. À peu près, je pense que tout le monde connaît, c'est déjà amusé avec ça. Alors, les curseurs, il y a une petite API. Tout le monde la connaît, je pense. Il y a le fameux execute. Il y a le fetch-all que tout le monde utilise. Sinon, il y a le fetch-one aussi, le fetch-many et le close, principalement. Maintenant, si vous avez une fonction, une procédure stockée, vous avez le call-proc. Vous voulez pas lancer le nom et les paramètres, et ça va l'interroger, une fonction qui se trouve stockée d'imposere. Alors, les curseurs, oui, il y a la fonction execute. Tout le monde s'amuse. À une époque, on ne va pas citer un certain langage, mais qui commence par P, qui se termine par HP. Et, oui, il y avait pas mal d'injections SQL. Psycho-PG vient directement avec respect quand même, la fonction execute, qui est définie sur les curseurs, mais rajoute des petits trucs en plus, parce que c'est définit dans la norme. C'est-à-dire que vous pouvez mettre des requêtes et dans la closeware, vous pouvez utiliser ces différents formatages et c'est Psycho-PG qui va s'amuser directement à faire la transformation pour éviter, par exemple, les commentaires. En MySQL, vous faites tirer-tirer à la fin d'une chaîne de caractère, et automatiquement, ça va passer en commentaire. Donc, ce qui veut dire qu'on peut acquier n'importe quoi. Voilà, un petit exemple un peu plus conclet. Un complet, pardon. On se connecte à la base de données, ça peut être ici une base de données, Postgre, ça peut être un PG Bounce ou n'importe quoi. C'est la même chose. On crée un curseur, on interroge. S'il y a eu un problème d'exception, on fait un rollback, sinon on fait un commit, et à la fin on ferme le curseur et on ferme la connexion. Necessaire à faire, parce que sinon, vous pouvez vite saturer votre connexion. Postgre est à la base à ce 32 ou 64 connexions. Alors, ils vont pas s'amuser avec du Silex, à essayer de discuter avec Postgre, donc ils sont amusés à utiliser Psycho-PG. Il y a un mec qui s'est amusé à développer Psycho-PG. Ensuite, Psycho-PG 2, donc c'est vraiment la base pour pouvoir discuter avec Postgre. Ça reprend l'entièreté de la DBAPI 2. Donc c'est libéré et c'est, comment dire, basé sur la lit de PQ, donc c'est pas du torchon que vous utilisez pour vous essuyer, c'est simplement un truc qui est utilisé pour discuter avec Postgre SQL. Ça gère le SSL, tout le tralala, donc vous cassez pas trop la tête, ça fonctionne bien. Alors, c'est DBAPI compliant, c'est multithrètes, il y a un pool de connexion qui est fourni directement. Si vous ne savez pas, ça vient de sortir. C'est fou la Synchron, parce qu'il y a le Listen Notify que vous pouvez utiliser. Si vous voulez jouer avec des websockets et tout le tralala, postgre le faire. Gestion des core routines et alors forcément, tout ce que vous avez vu en bus, tout ce qui est cool, etc. JSON, HSTOR, JSON B et d'autres trucs, c'est géré, donc il n'y a pas trop de problèmes. Si vous avez vu un truc à la mode, ça sort. Forcément, Python 2.5, 3.1, 3.4, 3.5, parce que c'est sorti hier, et Postgre à partir de 7.4. Alors, ça reprend l'enterreté de ce qui existe, donc les curseurs, etc. Le curseur, comme j'ai déjà expliqué, ça interroge directement. Et alors, il est nommé, c'est simplement pour les server-side. Vous voyez, ça respecte vraiment la même chose. Donc, on a aussi la requête SQL, c'est des exemples simples que tout le monde connaît, il n'y a pas de problème. Ensuite, c'est un exemple simple aussi. Alors, là, ce qui est bien avec Psycho-PG, c'est quand on débute avec Python, et surtout avec Psycho-PG, on s'amuse à faire un connect, un curseur, un execute, un rollback, quand il n'y a pas de problème, un commit, et après, on close le tout. Mais grâce à Python, on a les context managers, et surtout, Psycho-PG, c'est dit, tiens, on va développer l'utilité de Weas. Non, ils sont amusés avec ça, donc ça fait un peu plus court. Vous inquiétez pas, le code que j'ai vu là, professionnellement, j'en ai déjà vu qu'ils le faisaient. Donc, par contre, là, c'est pas mal. J'en vois très peu qui l'utilisent. Alors, qu'est-ce que c'est ? Maintenant, on va voir la partie objet ORM. Donc, les ORM, en gros, d'après Wikipedia, c'est une technique de programmation, créant l'illusion d'une base de données orientée aux objets à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé. C'est copier-coller, ces cités, Wikipedia. En bref, c'est comment mapper une classe business sur une table ? Il faut pas casser la tête, et ça propose différentes méthodes, style, lire, ajouter, modifier, supprimer et rechercher. En gros, un creud. Alors, pour pouvoir commencer, on a PIEWI ORM. Je l'ai pris, il y en a d'autres. Il y a un truc qui s'appelle Pony, etc. J'ai pas voulu faire de... C'est le premier que j'ai utilisé. Donc, là, je me suis dit, il était cool. PIEWI PINSTALL PIEWI, voilà. Donc, c'est un petit ORM assez basique. C'est simple, facile à comprendre. Extensif, piton 2, 6, 3, 2. Il y a des extensions, il y en a une vingtaine, trentaine. C'est assez facile. En plus, vous pouvez les rajouter très facilement. 3200 lignes de code, vous pouvez lire. Ça vaut la peine pour un apprentissage. C'est nickel, le code est lisible. Super lisible. Et c'est un fichier. C'est pas un spaghetti avec 40 000 fichiers partout, comme notre pote Eskelel Kimi. Mais au moins celui-là, pour débuter, c'est bien. Si vous voulez la théorie des ORM, ça, c'est nickel. Très bonne documentation, donc on se casse pas trop la tête. Alors, la connexion, voilà. Une ligne, on casse pas la tête. Alors, ça fonctionne principalement avec des modèles. Donc d'habitude, les gens s'amusent à faire des crées table dans un fichier SQL, dans un fichier Python, et ensuite, ils le lancent sur la base de données et se disent, OK, ça va fonctionner, peut-être. Ici, on définit les modèles. Et ensuite, il y a simplement le système qui va dire, tiens, on peut créer les tables. Donc de cette manière-là, il va créer les tables. Il y a un paramètre, c'est Fégaltro qui dit gentiment, si la table existe déjà, pas besoin de la recréer. Elle existe déjà. Voilà. Alors, PII, comme dans une base de données, on a des transactions, PII le permet. C'est database.transaction. Vous avez votre connecteur, vous girez ça. Les wisdoms, qui sont présents. Alors, un exemple d'un create, après, on va avoir le read, le write, etc. Le create, c'est simple. On a notre modèle, on fait .create. Juste au-dessus, on avait fait une transaction. Donc là, on est dans une transaction. On crée, on crée, on apprime, c'est tout. Ça se casse pas la tête. Pas besoin de faire d'un insert, execute ou quoi que ce soit. IDM, la même chose avec le read. Donc, vous avez la méthode get, la méthode select, la méthode where. Donc, en gros, oups, pardon. Ici, vous avez le contact, c'est votre modèle. Vous faites un select, vous récupérez un query builder. Le query builder, à la fin, vous pouvez vous amuser à lui rajouter des conditions au fur et à mesure. Donc, vous pouvez avoir différentes variables qui font différents scopes de données. À ce moment-là, vous pouvez directement les récupérer, les gérer. Alors, l'update, c'est pas plus compliqué. Vous reselectionnez l'élément qui vous intéresse. Vous modifiez un attribut, vous le mettez à jour. Voilà. IDM, pour le delete, vous avez la fonction delete où vous faites un where. Après, vous sélectionnez les informations qui vous intéressent et vous faites un execute. C'est tout. Sinon, si vous travaillez sur un item, une instance, vous la sélectionnez et vous pouvez faire delete instance. Ça va. On met la main devant la bouche quand on boit. Alors, SQL alchemy, c'est le bazooker. C'est un peu les USA contre, je sais pas, la polynesie ou un truc comme ça. Et vous avez de quoi travailler. Parce que, honnêtement, il y a un gestionnaire de... Je n'ai pas fait une grosse description d'escalier alchemy. Armin ornature, on a fait une superbe. Ça valait la peine. Mais ici, c'est vraiment pour aller vite. Donc, vous avez l'abstraction des connecteurs, langage d'expression SQL et cet ANORM. Donc, pour pouvoir se connecter, voilà. Alors, bien évidemment, ça gère différentes bases de données. Mais ici, c'est Postgre. Là, c'est ça qui nous intéresse. Quand vous mettez 3 slashes, c'est en local, c'est en unique socket. Il n'y a pas trop de problèmes, pas besoin de se casser à tête avec Postgre. Alors, les modèles, ça revient sur la même chose que PII. Il y en a un qui s'est basé sur l'autre. Je crois que c'est PII sur SQL et Kimi, forcément. Donc, vous voyez un petit peu comment ça fonctionne. Comment créer les bases de l'étable. Donc, vous avez des metadata. Vous lui donnez ce qu'il faut et il va les créer. Vous avez des sessions pour pouvoir gérer les transactions. Donc, commit, rollback et tout le travail là. Vous avez la possibilité de créer. Donc, on voit un petit peu, on fait un objet. On a vraiment un objet en mémoire. On l'ajoute dans la session, on fait un commit. Entre temps, vous pouvez faire un flush. Si vous faites des checkpoints, vous pouvez utiliser ça avec Postgre. Alors, le read, c'est la même chose. Vous avez votre session, récupérez l'objet et vous travaillez dessus, etc. L'update, le delete, voilà. Ça, c'était la partie SQL Kimi. Alors, maintenant, comment est-ce que vous faites une migration de base de données? Pardon? Ça aussi, tu utilises Django, mais c'est mort. Maintenant, tu peux utiliser Django 1.8. Mais il y a quoi d'autre? Oui, tu as Alambic, moi surtout, c'est de ça que je veux parler, ne me casse pas, merci. Non, je déconne. Mais alors, tu as Alambic qui a été créé gentiment par le développeur de SQL Kimi. C'est une très bonne application. Est-ce que SQL Kimi gère 8 bases de données, si je me souviens bien? Allez, 7, oui, peut-être. Et Alambic est basé dessus par le même développeur. Donc, c'est vraiment très, très intéressant. Alors, comme je dis sur SQL Kimi, ça utilise un environnement de migration. Donc, un peu, si vous jouez avec des guides et autres, vous avez un semblant de choses comme ça, c'est-à-dire que vous pouvez créer l'immigration de base qui va initialiser le schéma de base. Et ensuite, vous pouvez avoir des différentes étapes, donc différentes chances, qui vont se baser sur une référence parent. Donc, oui, une référence parent. Et vous allez pouvoir le gérer de cette manière-là. Donc, pour pouvoir utiliser, ça, c'est simple. Créer votre projet, vous allez dans votre projet, vous faites Alambic init immigration. Et automatingement, vous allez avoir ceci, un petit répertoire qui contient, c'est un template. Et vous allez pouvoir le modifier. Donc, pouvoir ajouter, par exemple, une révision. Donc, dis, je passe de l'étape du schéma 0 au schéma 1. Mais vous avez ceci, un upgrade et un downgrade. De cette manière, pouvez revenir en arrière si jamais vous avez constaté un bug. Alors, vous avez la version pour pouvoir ajouter au fur et à mesure. C'est la même chose. Il n'y a pas trop de problèmes de compréhension. Mais vous voyez qu'à chaque fois, on a un SHA-1 qui est balancé, un petit SHA-1 qui est balancé avec les différents noms des fichiers. Et ce qui est bien, c'est que lorsque vous allez faire l'immigration de base de données avec Alambic, vous allez avoir directement le versioning du schéma dans la base de données. Donc, vous pouvez le récupérer et travailler dessus. Alors, on peut s'amuser à faire un upgrade, passer de l'un à l'autre. Et tout ce qui est intéressant, si vous travaillez avec SQL Alchimie, vous pouvez réutiliser tous les modèles que vous avez déjà implémentés ailleurs dans votre projet. Donc, par exemple, un dore copie-coller, ce qui existe et ainsi de suite. Alors, il y a différentes commandes qui existent. Donc, vous avez révision, upgrade, upgrade plus, 1, 2. Donc, c'est-à-dire, vous êtes à un certain niveau. Vous les passez au niveau plus 2, upgrade plus 2. Revenez en arrière ou refaire un init. Ça fonctionne bien aussi. Il peut vous dire le current. Et l'historie, simplement pour vous dire où vous en êtes. Donc, si vous voulez savoir, etc., c'est comme le log avec un guide. Alors, maintenant, c'est la partie dangereuse. Parce que là, on peut en flinguer plusieurs, surtout sa base de données. Et on peut rendre son DBA un peu fou. Ah, DBA, oui. Son administrateur, DBA. Alors, multicorm, qu'est-ce que c'est exactement ? C'est une implementation écrite en Python, des foreign data wrappers, de PostgreSQL. Donc, en gros, les data wrappers, ça permet d'interroger, à la base, en version 9.2, c'était en lecture sol des sources. Même maintenant, avec la version 9.3, 9.4, 9.5, c'est en écriture aussi. Donc, depuis Postgre, vous pouvez faire un select vers un... Allez, par exemple, je vais donner un exemple. Un système, une API REST où vous faites un mapping dessus, vous pouvez faire un select depuis votre Postgre. Ça va interroger via de l'HTTP directement le service REST. Maintenant, vous pouvez faire un update, et automatiquement, ça va faire un poste sur la base de... Sur le service. Donc, à une époque, pour pouvoir les écrire, c'est en C. Ils sont dit, voilà, on va s'amuser. Là, c'est le foreign data wrapper pour discuter avec Mongo. Mais c'est un peu lourd. Donc, multicorm, c'est une petite extension Postgre, pas très connue, en fait, mais qui fonctionne bien, écrit en C avec la API de Postgre, utilisable en Python directement. Et tous les outils que vous utilisez avec SQL peuvent être directement utilisés sur le foreign data wrapper, c'est-à-dire, en gros, tout, tout ce que vous voulez faire. Et bien évidemment, ça supporte le full SQL. Alors, des exemples, tout à l'heure, j'ai déjà dit, on a le RSS, le CSV, l'XML, mais vous pouvez interroger, par exemple, un LDAP, un OpenLDAP, par exemple. Vous avez dans une entreprise un serveur d'identification, un Active Directory ou un LDAP, Postgre peut aller s'interroger. Si, par exemple, il y en a certains et qu'ici, on travaille avec Odu, voilà, merci. Et bien, comme on dit, on pourrait utiliser LDAP pour faire l'authentification des utilisateurs sur le système en utilisant directement Postgre comme base de données principale. On peut interroger Gmail, Imab, Google Search, SQLalchemy, si vous voulez faire un mapping avec d'autres bases de données. Alors, pour pouvoir l'utiliser simplement, c'est créer d'extension multicorne. Dans Debian ou Ubuntu, ça peut être qu'il installe multicorne. Casse pas la tête. Alors, ici, c'est l'exemple. C'est comment configurer directement le connecteur flu RSS. Donc, je lui dis, tiens, je vais utiliser tel WAPER qui est pour les RSS. Je vais le configurer de la manière suivante. Ça veut dire que j'ai une date de publication, une description, un titre, un lien. Et je lui donne des différents paramètres. En l'occurrence, mon URL à moi. J'ai essayé de le faire tout à l'heure avec Montréal Python, mais je me suis un peu vautré, donc je me suis dit, je vais garder ça. Et alors, en gros, non, c'est de ma faute. J'ai un Mac, c'est de la merde. Non, je déconne. Voilà. Non, je n'ai pas beaucoup de Wi-Fi. Et ici, j'ai pris une connexion pour un giga et ça rampe bien. Alors, par exemple, vous pouvez faire un select sur la base de données, sur la table externe. Et en fait, vous voyez, là, j'ai récupéré les résultats depuis le serveur externe. Donc, on peut laisser votre imagination à faire n'importe quoi. Alors, c'est un exemple avec OpenRP, parce que, comme je l'ai dit, j'ai développé pendant six ans chez OpenRP, qui est un ERP, un projiciel de gestion d'entreprise. Et ici, je montre comment pouvoir se connecter à OpenRP en XML-RPC depuis Postgre. Donc, en gros, là, c'est le bout de code. Vous voyez, c'est compliqué. Il faut 3000 lignes de code, comme le Mongo FDW. Ici, vous faites des hittages. Simplement, vous avez utilisé un connecteur XML-RPC. Voilà, c'est tout. Et là, vous faites directement l'arquête SQL. L'arquête que vous allez balancer l'arquête. Et au niveau de Postgre SQL, vous configurez votre connecteur. Vous allez dire, voilà, je vais avoir une table externe qui va se mapper sur un système, à part. Et quand je fais une requête, en fait, je vais directement voir le résultat. Donc, ça, c'est la partie multicorne. Qui connaissait multicorne ? Personne. Pune, super. Ça valait le peine que je viens. Qui connaît Palepighton ? Trois. T'as levé le doigt ? Trois, super. Alors, saviez-vous que vous pouviez étendre Postgre SQL ? Oui, non, peut-être, peut-être pas. Ça va, il y a quand même des têtes qui font, super, cool. Je ne suis pas bête. Non, je déconne. Mais voilà, alors, Palepighton, en fait, ça peut, c'est simplement l'utilisation de l'alibré Python. C'est embarqué directement dans Postgre au moment de la compilation. Donc, ça a eu, Tilly, soit de la version 2 de Python, soit de la version 3. On reprend la version 3.5 qui est sortie hier. On peut la compile directement, ça fonctionnera. Alors, ça permet d'utiliser toutes les librairies que vous avez dans PyPy. Request, ce que vous voulez, NumPy, etc. Tout ce que vous voulez, il n'y a pas de problème. Et bien évidemment, c'est un peu plus simple si vous connaissez Python que d'utiliser PSG SQL, ou PLjava, ou PLpearl, ou PLv8. Donc, pour l'installer, c'est pas bien difficile. Appétit, gain install, Postgre, PLpighton, etc. Et ensuite, pour l'activer dans votre Postgre, c'est create extension PLpighton. Là, c'est pour que ça ne crie pas quand on l'a déjà installé. Alors, un petit exemple. Savez-vous qu'il n'existe aucune fonction pour faire un title d'une chaîne de caractère. Donc, vous avez marqué Hello World. En minuscule, vous voulez avoir Hello World avec le H et le W en majuscule. Bien, j'ai implémenté une petite fonction qui utilise du Python tout bêtement. Et là, j'ai sélect str title. C'est comme une fonction Postgre. Il n'y a pas de problème. Vous pouvez l'utiliser. Donc, en gros, faites ce que vous voulez. Alors, ça supporte les différents datatypes de Postgre. Donc, on a une table de mapping, integer, int, Boolean, Boole, text type, str, escalary list, custom type et syndictionnaire. Alors, dedans, on peut s'amuser à utiliser soit des notices, des debuts, erreurs et fatales. On oublie le print pour la simple et bonne raison, c'est que vous n'avez pas accès au SDAout. Vous devez directement utiliser le PLpy avec les différentes fonctions pour pouvoir envoyer dans les logs de Postgre. Alors, un exemple un peu plus concret. Un jour, je me suis dit, tiens, je dois bien savoir. Vous savez, quand vous connectez sur Postgre SQL, vous avez un PID. Donc, vous avez une application cliente qui est au SDAout. Postgre, il a une table qui dit, lentiment, l'application X utilise, comment dire, autant de CPU, autant de RAM, etc. En fait, c'est simplement, voilà. En gros, moi, je voudrais savoir quel est le pourcentage de CPU et de mémoire que le process client utilise. Donc là, j'ai fait une petite fonction qui utilise une e-brake, ça s'appelle PSutile. Si vous ne connaissez pas, c'est for-utile, surtout en administration au système pour gérer le process. Et je dis, voilà, maintenant, je vais commencer à regarder dans ma base de données. Donc, donne-moi un peu le statut de toutes les applications qui sont connectées. Ici, j'en ai une. C'est le PID qui m'attaise, c'est le 14680. Et c'est avec PSQL. J'aimerais bien, s'il te plaît, que tu me donnes l'utilisation CPU, l'utilisation mémoire. En glage, j'interroge ma petite fonction. C'est rien, c'est mon timer. Merci. Et qui va utiliser la fonction qui est définie juste là. Ça va ? Alors après, qu'est-ce qui se passe ? On peut s'amuser à faire pas mal de choses, à interroger un système, un serveur, n'importe quoi. Donc voilà. Alors, maintenant, BPL Python, alors c'est complètement un serveur. Il n'y a pas de sandbox. C'est-à-dire qu'en gros, il a été prouvé qu'on ne peut pas sandboxer Python. On ne peut pas interdire une personne d'aller interroger le système, le fichier ou quoi que ce soit. Donc, on ne peut pas empêcher une personne de péter une base de données, détruire un fichier ou quoi. C'est pour ça que BPL Python, ah oui, et de plus, c'est utilisé principalement avec un super user. Donc, faites très attention. Si vous l'utilisez, c'est, comment on dit encore là, c'est signer votre arrêtement avec votre boss. Un truc comme ça. Et enfin, bref, alors, c'est très difficile à maintenir. J'ai eu la preuve et à débugger. Ça, c'est encore mieux. Comment rendre fou d'un DBA ? Il n'y a pas de virtuel Anf. Donc, ça utilise le piton qui se trouve lancé dans l'environnement de post-grès. Et ça demande, oui, c'est ce que je disais, ça demande des privilèges super user. Alors, il y a des petites pistes pour quelle raison est-ce que ça serait intéressant ? Ben, traitement sur de gros volumes de données. Donc, vous avez 10 millions de records. Ben, en fait, qu'est-ce qui va se passer ? Vous allez interroger avec piton directement post-grès SQL. Ben, post-grès, vous lancez. Il y a un process post-grès qui va être lancé, qui va utiliser piton. Et tout le traitement va se faire dans le piton, dans post-grès. Donc, ça va être assez rapide. Il n'y a pas besoin de faire de sérialisation, de sérialisation au niveau du protocole de post-grès. Donc, c'est assez balèze. Si vous voulez vous amuser à rajouter des contraintes business, vous le faites directement là-dedans. Moi, je le déconseille, parce que sinon, ben, si jamais on arrête de supporter PL-Piton, ben, c'est fini. Alors, vous pouvez rajouter de nouvelles fonctionnalités, vous pouvez l'utiliser dans les triggers, utilisation des livres de pipi, comme je le disais tout à l'heure. Et vous pouvez faire ce que vous voulez. Alors, j'ai une question à vous demander. Comment est-ce qu'on peut déterminer la date de création d'une base de données avec post-grès ? Je ne sais pas, il n'y a pas de solution. Il n'y en a pas. J'ai le posé à la question. Il y a une métatable dans post-grès, on pégé date à base, vous lui demandez, tiens. Quels sont les bases de données ? Tac, il y en a vingt. Qu'est-ce qu'il y a de la date de création ? Je ne sais pas. Voilà, c'est comme ça, c'est comme ça que ça fonctionne. Mais donc, vous pouvez utiliser PL-Piton pour interroger. Donc, voilà, si vous avez des petites questions, ben, c'est après le drink.