APIBASE NQL traduit les demandes en langage naturel en coordonnées APIBASE déterministes. L’utilisateur pose sa question simplement. APIBASE résout les tables, colonnes, opérateurs et relations avec les outils API ou Hive autorisés.
APIBASE NQL translates natural language requests into deterministic APIBASE coordinates. Users ask in plain language. APIBASE resolves tables, columns, operators and relationships through authorized API or Hive tools.
Token HIVE en lecture seule · Base de connaissances APIBASE · Propulsé par Claude HaikuRead-only HIVE token · APIBASE knowledge base · Powered by Claude Haiku
NQL signifie Natural Query Language. C’est la couche de langage naturel d’APIBASE.
NQL means Natural Query Language. It is the natural language layer of APIBASE.
NQL ne remplace pas APIBASE, SQL ou l’API Hive. Il se place au-dessus d’APIBASE et traduit l’intention humaine en opérations déterministes : découverte du schéma, résolution des tables et colonnes, filtres, relations et calculs contrôlés.
NQL does not replace APIBASE, SQL or the Hive API. It sits above APIBASE and translates human intent into deterministic operations: schema discovery, table lookup, column resolution, filtering, relationship traversal and controlled calculations.
// NQL model
Human request → APIBASE NQL → MCP tools → Hive / API requests → T / L / C / O coordinates → Authorized resultNQL peut comprendre des formulations proches de SQL, mais ce n’est pas SQL. Il ne promet pas la compatibilité SQL, la syntaxe JOIN ou l’accès direct à une base de données.
NQL may understand SQL-like phrases, but it is not SQL. It does not promise SQL compatibility, JOIN syntax or direct database access.
NQL est une couche d’intention. Il interprète la demande, résout les structures APIBASE nécessaires, puis exécute des opérations API ou Hive autorisées.
NQL is an intent layer. It interprets a request, resolves the required APIBASE structures, then executes authorized API or Hive operations.
// SQL-like input accepted as intent
BASE pierre
SELECT orders FROM customers WHERE customer = "Acme Inc."
// APIBASE interpretation
1. Resolve customers schema
2. Resolve orders schema
3. Find customers.customer matching "Acme Inc."
4. Extract id_customer
5. Query orders.customer_id = id_customer
6. Return authorized ordersUne couche d’intention naturelle qui résout les coordonnées APIBASE.A natural intent layer that resolves APIBASE coordinates.
Outils MCP, ACLs Hive, bearer tokens et adressage TLC.MCP tools, Hive ACLs, bearer tokens and TLC addressing.
Compatibilité SQL, requêtes illimitées ou accès direct à la base.SQL compatibility, unrestricted querying or direct database access.
NQL ne demande pas à l’utilisateur de coller un bearer token. L’utilisateur est déjà authentifié; APIBASE résout son token actif, puis applique les ACLs Hive avant l’exécution.
NQL does not ask the user to paste a bearer token into the form. The user is already authenticated. APIBASE resolves the selected or default active token, then applies Hive ACLs before executing.
La demande naturelle est convertie en plan d’exécution. Ce plan liste chaque table touchée et le droit requis. APIBASE vérifie ces droits avant l’exécution MCP ou Hive.
The natural request is converted into an execution plan. That plan lists every table touched by the operation and the required right for each table. APIBASE checks those rights before MCP or Hive execution runs.
// Secure NQL execution
Authenticated user → active token check → hivebase resolved → required rights → hiveacls verification → authorized execution → filtered resultorders, mais le plan touche aussi customers.A request that finds orders through customers checks both tables. The final result may come from orders, but the plan also touches customers.Un utilisateur peut poser une question d’affaires simple en langage courant. NQL transforme la demande en séquence d’appels aux outils MCP APIBASE.
A user can ask a simple business question in plain language. NQL turns the request into a sequence of APIBASE MCP tool calls.
// User request
In the pierre base, find the orders for customer Acme Inc.
// NQL interpretation
base = pierre
target = orders
source = customers
filter = customer contains "Acme Inc."
relationship = orders.customer_id → customers.id_customer
// MCP execution plan
apibase_schema(base="pierre", table="customers")
apibase_schema(base="pierre", table="orders")
apibase_query(base="pierre", T=<customers>, C=<customer>, operator=28, value="Acme Inc.")
apibase_query(base="pierre", T=<orders>, C=<customer_id>, operator=1, value=<id_customer>)NQL peut répondre à des demandes orientées résultat, comme des totaux, comptes ou résumés. APIBASE fournit les données autorisées; NQL calcule au-dessus.
NQL can also answer outcome-based requests, such as totals, counts or summaries. APIBASE provides the authorized records and values. NQL performs the calculation above.
// User request
In the pierre base, give me the sum of all orders for customer "Acme Inc."
// Execution plan
1. Resolve customers schema
2. Resolve orders schema
3. Query customers where customer contains "Acme Inc."
4. Extract id_customer
5. Query orders where customer_id equals id_customer
6. Read total.amount from each authorized order
7. Sum the values in the NQL layer
8. Return the resultNQL commence avec un ensemble réduit et fiable d’intentions. Le but n’est pas de comprendre toutes les phrases possibles, mais de traduire des demandes utiles de façon sûre.
NQL starts with a small, reliable set of intents. The goal is not to support every possible sentence. The goal is to translate useful business requests safely.
“Find customers where customer contains Acme.”
“Get orders for customer Acme Inc.”
“What is the email of customer 14?”
“Sum the orders of customer Acme Inc.”
“How many orders are pending?”
“Set order 42 status to shipped.”
Écrire en pseudo-langage NQL donne à l’IA une intention précise. Chaque mot-clé correspond à une opération APIBASE claire : lecture, filtre, agrégation, mise à jour ou inspection de structure.
Writing NQL in pseudo-language gives the AI a precise, unambiguous intent. Each keyword maps to a clear APIBASE operation: read, filter, aggregate, update, or inspect structure.
// Read operations
FIND [table] WHERE [col] = [val]
FIND [table] WHERE [col] BETWEEN [val1] AND [val2]
FIND [table] WHERE [col] IN LIST [val1] [val2] [val3]
RECENT [table] [n]
LAST [table] [n]
SHOW [table] L[id]
SHOW L[id]
COUNT [table]
COUNT [table] WHERE [col] = [val]
SUM [col] FROM [table] WHERE [col] = [val]
AVG [col] FROM [table] WHERE [col] = [val]
MIN [col] FROM [table]
MAX [col] FROM [table]
GROUP [group_col] SUM|AVG|COUNT|MIN|MAX [val_col] FROM [table]
SCHEMA [table]
// Write operations
ADD [table] [col=val, col=val, ...]
UPDATE [table] SET [col] = [val] WHERE L[id]
SET [table] id=[x] [col=val]
SET [table] WHERE [col] = [val] TO [col=newval]
REPLACE [table] [col] [old] → [new]
DELETE [table] id=[x]
DELETE [table] WHERE [col] = [val]
// Examples
LAST informations 4
SHOW informations L93
SHOW L93
FIND informations WHERE lang = fr
COUNT informations WHERE category = nql
UPDATE informations SET title = "Create an APIBASE BASE for free or with support" WHERE L93
SCHEMA informationsFIND n’est pas SELECT.
LAST et RECENT sont des alias pour afficher les derniers enregistrements d’une table.
Pour les modifications ciblées, UPDATE ... WHERE L[id] est souvent la forme la plus claire.
NQL keywords are not SQL.
They are shorthand for APIBASE operations.
FIND is not SELECT.
LAST and RECENT are aliases for showing the latest records from a table.
For targeted edits, UPDATE ... WHERE L[id] is often the clearest form.
LOBOC est un dialecte de NQL inspiré de la syntaxe COBOL. Il permet d'écrire des requêtes complexes
en chaîne, lisibles par des non-développeurs et auditables par des équipes métier.
Chaque étape nomme son résultat avec GIVING et l'étape suivante l'enchaîne avec WITH.
LOBOC is a NQL dialect inspired by COBOL syntax. It enables writing complex chained queries
that are readable by non-developers and auditable by business teams.
Each step names its result with GIVING and the next step chains from it with WITH.
// Read — LOBOC aliases for NQL keywords
SELECT [ALL] FROM [table] WHERE [col] EQUALS [val] GIVING [name]
SELECT [ALL] FROM [table] WHERE [col] GREATER THAN [val] GIVING [name]
SELECT [ALL] FROM [table] WHERE [col] LESS THAN [val] GIVING [name]
SELECT [ALL] FROM [table] WHERE [col] NOT EQUAL TO [val] GIVING [name]
SELECT [ALL] FROM [table] WHERE [col] CONTAINING [val] GIVING [name]
SELECT [ALL] FROM [table] WHERE [col] THRU [val1] [val2] GIVING [name]
SELECT [ALL] FROM [table] WHERE [col] BETWEEN [v1] AND [v2] GIVING [name]
SELECT [ALL] FROM [table] WHERE [col] IN LIST [v1] [v2] [v3] GIVING [name]
SELECT [ALL] FROM [table] WHERE [col] ONE OF [v1] [v2] [v3] GIVING [name]
FIND FIRST [table] GIVING [name]
DESCRIBE [table]
// Aggregation & Count
COUNT [table]
COUNT [table] WHERE [col] EQUALS [val]
TALLYING [table] WHERE [col] EQUALS [val]
COMPUTE SUM|AVG|MIN|MAX [col] FROM [table]
SUMMARIZE [table] BY [col] COMPUTING SUM|AVG|COUNT|MIN|MAX [col]
// Display named GIVING result (LOBOC SHOW ≠ NQL SHOW L[id])
SHOW [giving-name]
// Write — LOBOC aliases
INSERT INTO [table] [col=val, col=val, ...]
MODIFY [table] WHERE L[id] SET [col] = [val]
MODIFY [table] WHERE [col] EQUALS [val] SET [col] = [newval]
REWRITE [table] WHERE L[id] SET [col] = [val]
REWRITE [table] WHERE [col] EQUALS [val] SET [col] = [newval]
REMOVE FROM [table] WHERE L[id]
REMOVE FROM [table] WHERE [col] EQUALS [val]
BETWEEN et THRU sont deux syntaxes pour le même filtre de plage (opérateur 32).
BETWEEN est familier aux utilisateurs SQL ; THRU est l'équivalent COBOL.
Les deux produisent le même résultat.
BETWEEN and THRU are two syntaxes for the same range filter (operator 32).
BETWEEN is familiar to SQL users; THRU is the COBOL equivalent.
Both produce the same result.
FIND campagnes WHERE id_campagne BETWEEN 1 AND 50
FIND campagnes WHERE id_campagne THRU 1 50
// identical — both filter id_campagne from 1 to 50
IN LIST et ONE OF filtrent sur une liste de valeurs explicites (opérateur 33).
C'est l'équivalent du IN (…) SQL, sans parenthèses ni virgules.
IN LIST and ONE OF filter on an explicit list of values (operator 33).
This is the equivalent of SQL IN (…), without parentheses or commas.
FIND prospects WHERE secteur IN LIST Manufacturier Distribution
FIND campagnes WHERE id_campagne ONE OF 1 5 10
// IN LIST and ONE OF are identical — values separated by spaces
GIVING nomme un résultat. WITH l'enchaîne dans la requête suivante.
CORRESPONDING résout automatiquement la clé étrangère entre les deux tables via les rules APIBASE.
GIVING names a result. WITH chains it in the next query.
CORRESPONDING automatically resolves the foreign key between the two tables via APIBASE rules.
// Step 1 — find all campaigns ready to send (slave table)
FIND campagnes WHERE statut EQUAL TO pret GIVING cibles
// Step 2 — retrieve the linked prospects (master table)
// CORRESPONDING resolves the FK prospect_id automatically via rules
WITH cibles FIND prospects
campagnes est une table transaction qui contient un champ prospect_id.
CORRESPONDING détecte ce lien via les rules APIBASE et remonte automatiquement vers la table maître prospects — sans écrire la jointure.
Résultat : les prospects associés aux campagnes prêtes à l'envoi.
campagnes is a transaction table containing a prospect_id field.
CORRESPONDING detects this link via APIBASE rules and automatically navigates up to the master table prospects — without writing the join.
Result: the prospects linked to campaigns ready to send.
// Three-step chain — master → slave → master
FIND prospects WHERE secteur EQUAL TO Manufacturier GIVING secteur-cible
WITH secteur-cible
FIND campagnes CORRESPONDING WHERE statut EQUAL TO pret GIVING campagnes-actives
WITH campagnes-actives
COUNT prospects CORRESPONDINGWITH … CORRESPONDING résout la FK via les rules — aucun JOIN à écrire.
WITH est une frontière d'exécution : chaque étape est complète avant la suivante.
Seul le résultat final s'affiche — les GIVING intermédiaires sont des variables de pipeline invisibles.
LOBOC is not SQL.
LOBOC keywords are direct aliases for NQL/APIBASE operations.
WITH … CORRESPONDING resolves the FK via rules — no JOIN to write.
WITH is an execution boundary: each step completes before the next begins.
Only the final result is shown — intermediate GIVINGs are invisible pipeline variables.
L’interface la plus sûre sépare le choix de la base de la demande naturelle. L’utilisateur ne fournit pas de bearer token; le backend le résout à partir de la session.
The safest interface separates the base selection from the natural request. The user does not provide a bearer token. The backend resolves the token from the authenticated session.
Base: [pierre]
Token: [Default NQL token for this user]
Request: [Give me the sum of all orders for customer "Acme Inc."]
[Run NQL]NQL produit un plan d’exécution avant d’appeler APIBASE. Cela rend le système plus facile à déboguer, valider et auditer.
NQL produces an execution plan before calling APIBASE. This makes the system easier to debug, validate and audit.
1. Receive authenticated user, base and natural request
2. Resolve active token for the user
3. Detect intent
4. Identify target tables
5. Resolve schemas with apibase_schema
6. Resolve columns and relationships
7. Resolve required table rights
8. Check hiveacls
9. Build MCP tool calls
10. Execute authorized Hive/API requests
11. Calculate or format the result
12. Return a human-readable answerNQL utilise le serveur MCP APIBASE comme pont d’exécution. Le serveur expose des outils génériques qui correspondent aux opérations Hive.
NQL uses the APIBASE MCP server as its execution bridge. The MCP server exposes generic tools that map directly to Hive operations.
apibase_schema → discover T and C ids
apibase_query → query rows with an operator
apibase_get_cell → read one exact cell
apibase_get_record → read one full record
apibase_post → insert one record
apibase_put_cell → update one exact cell
apibase_put_line → update one full line
apibase_delete → delete one recordNQL devient puissant lorsque les schémas APIBASE respectent les règles structurelles. Une clé étrangère utilise le singulier du parent avec _id.
NQL becomes powerful when APIBASE schemas follow structural relationship rules. A foreign key uses the parent singular base with _id.
customers
C1 = id_customer
C2 = customer
orders
C1 = id_order
C2 = order
C3 = customer_id
C4 = order.status
C5 = total.amount
orders.customer_id → customers.id_customerCes exemples sont orientés affaires. L’utilisateur demande un résultat; NQL résout les coordonnées APIBASE nécessaires.
These examples are intentionally business-oriented. The user asks for an outcome. NQL resolves the required APIBASE coordinates.
In the pierre base, find the orders for customer Acme Inc.
In the pierre base, give me the sum of all orders for customer Acme Inc.
In the pierre base, which products are below the minimum stock?
In the pierre base, set order 42 status to shipped.
In the pierre base, summarize the activity for customer Acme Inc.NQL supporte les mises à jour de cellules exactes lorsque le token utilisateur a le droit requis et que la valeur demandée passe la validation.
NQL supports exact cell updates when the user token has the required right and the requested value passes validation.
User:
In the pierre base, set order 42 status to shipped.
NQL:
1. Resolve authenticated user token
2. Validate allowed status values
3. Resolve orders schema
4. Resolve C_order_status
5. Check orders edit right in hiveacls
6. Call apibase_put_cell
7. Return confirmationNQL est une branche claire de l’écosystème APIBASE. Il ne remplace pas Core ou Hive; il se place au-dessus.
NQL is a clear branch of the APIBASE ecosystem. It does not replace Core or Hive. It sits above them.
APIBASE Core → deterministic data coordinates
APIBASE Hive → controlled shared access
APIBASE MCP → AI tool bridge
APIBASE NQL → natural language access to coordinatesNQL commence avec un petit ensemble d’intentions fiables et garde le plan d’exécution visible. Les demandes naturelles deviennent explicables, testables et sécurisées.
NQL starts with a small set of reliable intents and keeps the execution plan visible for debugging. This makes natural requests explainable, testable and secure.
Natural request → authenticated user → active token resolution → intent detection → schema resolution → hiveacls verification → MCP tools → authorized APIBASE result