Créer depuis une table de base
Quand la table existe déjà dans la base, le chemin le plus rapide est l'Assistant CRUD. Vous le pointez sur un schéma et une table, cochez les colonnes que l'écran doit voir, marquez celles qui identifient une ligne, et Liberty écrit les quatre requêtes (_get, _put, _post, _delete) à votre place — y compris la reliaison :NAME_ORIGINAL sur UPDATE pour que l'Enregistrer d'un dialogue sache quelle ligne retrouver.
C'est le chemin recommandé pour toute table déjà existante. À éviter uniquement quand la table n'existe pas encore ou quand vous voulez du SQL écrit à la main — voir Créer une requête personnalisée.
Où le trouver
L'assistant est accessible depuis Paramètres → Connecteurs :
- Sélectionnez un connecteur dans la liste de gauche.
- Basculez la barre de modes du volet droit sur Tables.
- Cliquez sur ＋ Ajouter une table en haut à droite.
- Une fenêtre de choix s'ouvre. Sélectionnez Générer depuis la base.
L'assistant parcourt alors le pool du connecteur (GET /api/sql/<connector>/_schemas) et présente les schémas trouvés.
La disposition de l'assistant
Étape 1 — Sélectionner un schéma
Le sélecteur de schéma n'apparaît que si le pool en compte plusieurs. PostgreSQL avec un seul public et SQLite le sautent ; Oracle (plusieurs schémas) l'exige.
L'assistant récupère les schémas de manière différée — l'ouverture initiale liste juste les noms, le parcours table par table d'un schéma a lieu après votre choix. Sur un pool Oracle volumineux, ce comportement épargne la dizaine de secondes que prendrait un parcours multi-schémas complet.
Étape 2 — Filtrer les noms de tables (facultatif)
Un motif SQL LIKE (customers%, F00%) saisi dans le champ Filtre par nom restreint la liste des tables côté serveur, avant que l'introspection des colonnes ne s'exécute pour chacune. Pour des pools qui comptent des milliers de tables, c'est la différence entre un sélecteur réactif et un sélecteur lent.
Le filtre est temporisé — tapez librement ; la requête part environ 350 ms après l'arrêt de la frappe.
Étape 3 — Sélectionner la table
Une fois la table choisie, l'assistant récupère ses colonnes et pré-remplit deux ensembles :
| Ensemble | Règle de pré-remplissage |
|---|---|
| Incluses | Toutes les colonnes sont cochées. |
| Clés | Toutes les colonnes que la base marque NOT NULL sont cochées. |
Ce sont des suppositions — décochez les colonnes à ne pas exposer (BLOB, colonnes d'audit, champs calculés) et confirmez les clés.
Étape 4 — Cocher colonnes et clés
Chaque ligne de la liste Colonnes porte :
| Élément | Rôle |
|---|---|
| Case Inclure | Décochée, la colonne disparaît du SELECT de _get et de l'INSERT de _post. Le dialogue ne la verra pas. |
| Nom + type de colonne | En lecture seule — proviennent de la base en direct. |
| Bascule CLÉ | Fixée à droite. Cochée, cette colonne pilote la clause WHERE du _put (avec :NAME_ORIGINAL) et la clause WHERE du _delete. |
Une ligne avec au moins une clé est requise pour que UPDATE / DELETE produisent quoi que ce soit. L'assistant refuse d'enregistrer sans cela.
Étape 5 — Choisir les requêtes à émettre
Quatre cases à cocher — SELECT (_get), UPDATE (_put), INSERT (_post), DELETE (_delete). Cochez celles dont la table a besoin.
| Motif | À cocher |
|---|---|
| Table de référence en lecture seule. | SELECT uniquement. |
| Table CRUD standard. | Les quatre. |
| Ajouts seulement (journal d'audit). | SELECT + INSERT. |
| Table de référence éditée seulement par INSERT puis purge. | SELECT + INSERT + DELETE. |
La requête SELECT est toujours émise — au minimum, l'écran a besoin de lire la table.
Étape 6 — Lire l'aperçu, surcharger au besoin
La colonne de droite affiche le SQL généré pour chaque emplacement CRUD coché, en direct. Modifiez n'importe quel aperçu directement — votre modification prime sur la génération automatique tant que vous ne changez pas la sélection de colonnes/clés, ce qui restaure la version générée.
Les quatre formes
-- _get : SELECT direct sur les colonnes incluses
SELECT col1, col2, …
FROM <schema>.<table>
-- _post : INSERT lié à des placeholders :col
INSERT INTO <schema>.<table> (col1, col2, …)
VALUES (:col1, :col2, …)
-- _put : UPDATE des colonnes non-clés, WHERE sur la clé avec :NAME_ORIGINAL
UPDATE <schema>.<table>
SET non_key1 = :non_key1, non_key2 = :non_key2, …
WHERE key1 = :key1_ORIGINAL
AND key2 = :key2_ORIGINAL
-- _delete : DELETE sur la clé avec :NAME (le dialogue lie les valeurs actuelles de la ligne)
DELETE FROM <schema>.<table>
WHERE key1 = :key1
AND key2 = :key2
Pourquoi :NAME_ORIGINAL sur UPDATE ?
L'Enregistrer d'un dialogue envoie deux instantanés de chaque colonne clé : la valeur actuelle (:key1) et celle qu'avait la ligne à l'ouverture du dialogue (:key1_ORIGINAL). L'UPDATE filtre sur l'originale pour que la ligne soit retrouvée même quand l'opérateur a modifié la clé elle-même. L'Assistant CRUD câble cette convention pour vous — si vous écrivez plus tard un _put à la main, reproduisez-la.
Étape 7 — Enregistrer
Le bouton Enregistrer :
- Ajoute les requêtes cochées à la liste des requêtes du connecteur.
- Sauvegarde le fichier connecteur.
- Déclenche un rechargement à chaud — les nouvelles requêtes sont appelables immédiatement.
Les quatre nouvelles requêtes apparaissent dans l'onglet Tables regroupées sous leur nom de base commun, avec les quatre badges d'emplacement CRUD indiquant celles qui ont été émises.
Validation — ce qui bloque l'enregistrement
| Erreur | Cause | Correction |
|---|---|---|
| Sélectionnez une table. | Aucune table sélectionnée. | Sélectionnez-en une. |
| Nommez la table. | Le champ nom de base est vide (déduit du nom de la table ; effacez-le pour le surcharger). | Saisissez un nom de base — lettres, chiffres, tirets bas. |
| Incluez au moins une colonne. | Toutes les colonnes ont été décochées. | Cochez-en au moins une. |
| La requête de lecture (_get) est obligatoire. | SELECT a été décoché. | Recochez-le. |
| Choisissez au moins une colonne clé pour UPDATE / DELETE. | UPDATE ou DELETE est coché mais aucune colonne n'a CLÉ activée. | Marquez la ou les colonnes clés. |
| Une requête nommée « X » existe déjà. | Le nom de base produit un <base>_get (ou _put / _post / _delete) en collision avec une requête existante sur ce connecteur. | Choisissez un autre nom de base, ou supprimez d'abord l'ancienne. |
Ce que vous venez de bâtir
Pour une table customers avec customer_id comme clé, l'assistant a généré quatre requêtes :
| Nom | Type | Utilisée par |
|---|---|---|
customers_get | table (lecture) | La lecture de la grille + formulaire. |
customers_put | table (écriture) | L'Enregistrer du dialogue (UPDATE). |
customers_post | table (écriture) | L'Enregistrer du dialogue (INSERT). |
customers_delete | table (écriture) | L'action Supprimer de la grille. |
Elles atterrissent dans l'onglet Tables sur une ligne libellée customers avec les quatre badges GET / PUT / POS / DEL tous verts. L'étape suivante est de construire un écran par-dessus — couverte dans la prochaine section Écrans.
Quand utiliser l'assistant ou écrire à la main
| Utiliser l'assistant | Écrire à la main (Ajouter une requête sur Non classées) |
|---|---|
| La table existe en base. | La requête est un rapport personnalisé, un agrégat ou un appel de procédure stockée. |
| Vous voulez les quatre formes CRUD standard. | Vous avez besoin d'un JOIN, d'un GROUP BY, d'une CTE RECURSIVE. |
| Vous partez de zéro et les colonnes sont la source de vérité. | Vous voulez une requête qui ne se projette pas 1 pour 1 sur une table. |
L'assistant est le bon outil pour 80 % des tables opérationnelles. Les 20 % restants — analytique, rapports, jointures multi-tables — passent par Créer une requête personnalisée.
Et ensuite
- Créer une requête personnalisée — quand l'assistant ne convient pas.
- Dupliquer une requête ou un connecteur — partir d'une requête existante plutôt que de zéro.
- Liaison de paramètres — donner aux paramètres
:placeholderlibellés, valeurs par défaut et valeurs liées depuis les écrans.