3 points par GN⁺ 2024-11-20 | 5 commentaires | Partager sur WhatsApp
  • Une extension qui permet d’intégrer la base de données SQLite elle-même dans des tables PostgreSQL via un type de colonne SQLITE
    • Cette approche permet de résoudre la multitenancy
  • Création d’une base vide avec empty_sqlite : CREATE TABLE people (name TEXT NOT NULL, database SQLITE DEFAULT execute_sqlite(empty_sqlite(), 'CREATE TABLE todos (task TEXT)'));
  • Requêtes possibles avec la fonction query_sqlite, insertions/mises à jour possibles avec execute_sqlite
    • SELECT * FROM query_sqlite(database, 'SELECT * FROM todos');
    • `UPDATE people SET database = execute_sqlite(database, 'INSERT INTO todos VALUES (''solve multitenancy'')') WHERE name = 'frectonz';
  • Lecture d’une colonne spécifique avec les fonctions get_sqlite_text/get_sqlite_integer/get_sqlite_real : SELECT get_sqlite_text(sqlite_row, 0) FROM query_sqlite(database, 'SELECT * FROM todos');
  • Écrit avec Rust + le framework Pgrx
  • Détails d’implémentation :
    • La base est stockée sous forme de Vec<u8> encodé en CBOR (Concise Binary Object Representation)
    • Lors de l’exécution d’une requête, elle est créée comme fichier aléatoire dans le dossier /tmp. SQLite charge alors le fichier, exécute la requête et renvoie le résultat dans une table à ligne unique contenant des valeurs encodées en JSON

5 commentaires

 
sms8377 2024-11-22

WAOUH..

 
seunghaekim 2024-11-20

Mon Dieu...

 
xguru 2024-11-20

C’est une extension un peu étrange, mais je me dis que ça pourrait peut-être servir dans des cas comme la création d’un SaaS extensible, quand les utilisateurs ont besoin d’intégrer simplement des fonctionnalités de base de données.

 
GN⁺ 2024-11-20
Commentaires Hacker News
  • La plupart des systèmes de gestion de bases de données relationnelles ne prennent pas en charge les enregistrements imbriqués, et SQL manque lui aussi de fonctionnalités pour créer ou exploiter des tables imbriquées

    • Certains répondent : « avec cette attitude, ça ne marchera pas »
  • Proposition d’une idée consistant à empaqueter le répertoire d’une base PostgreSQL dans une archive tar, puis à l’encoder en blob binaire dans SQLite

    • Ce n’est ni très pratique ni particulièrement utile, mais cela illustre le concept d’imbriquer des bases SQL
  • Des doutes sont exprimés sur les cas d’usage de cette idée

    • Difficile à utiliser lors de la conception du schéma de base de données d’un produit classique
    • Certains se demandent si cela pourrait servir, dans une application hybride, à sauvegarder directement les données utilisateur locales avec les informations de compte
  • Avis selon lequel une colonne SQLite serait supérieure à une colonne JSON dans SQLite

    • Les opérateurs JSON imposent d’apprendre un langage de requête séparé et restent limités
  • Le mécanisme de fichier /tmp semble être un hack, et sa nécessité est remise en question

    • Il serait peut-être possible de créer une base SQLite en mémoire, puis d’utiliser l’API de sauvegarde ou VACUUM INTO pour charger les données du blob binaire
  • Si l’on utilise PostgreSQL, le problème du multi-tenant peut être résolu via la Row Level Security (RLS)

    • Il est très simple d’ajouter une colonne d’ID de tenant à chaque table et de définir une politique permettant à un seul tenant de voir les données
  • Un crime contre la 1NF (première forme normale) ?

  • Plaintes au sujet de l’absence d’opérateurs

    • Certains voudraient des index et une syntaxe d’opérateurs originale pour faire des jointures inter-bases entre plusieurs colonnes DATABASE