Une requête planifiée, c'est du SQL plus une planification cron. À chaque déclenchement, Canner exécute le SQL pour vous à Montréal et enregistre le résultat. Le SQL est libre : il peut faire un SELECT, ou CREATE TABLE, INSERT, UPDATE, MERGE— ce dont la tâche a besoin. C'est le pendant SQL d'une tâche planifiée, qui, elle, appelle un webhook de votre application.
Référencez vos bases par leur nom
Une requête planifiée peut atteindre n'importe quelle base de projet que votre compte possède, référencée par le slug du projet — projet.schema.table (le schéma est généralement public). Aucun menu déroulant, aucune étape d'« attachement » : nommez une base dans le SQL et Canner vous y connecte, en lecture et en écriture. Comme vous pouvez en nommer plusieurs, une seule requête peut joindre ou déplacer des données entre projets. (Un trait d'union dans un slug devient un tiret bas dans le nom — le projet ma-boutique s'écrit ma_boutique.public.table.)
Où vont les résultats
Rien n'est matérialisé à votre place — c'est le SQL qui décide. Qualifiez une table avec un projet et elle est créée dans la vraie base Postgres de ce projet, où votre application peut la lire :
-- Nightly rollup written into your project's own Postgres.
CREATE OR REPLACE TABLE shop.public.daily_sales AS
SELECT date_trunc('day', created_at) AS day,
count(*) AS orders,
sum(amount) AS revenue
FROM shop.public.orders
GROUP BY 1;Un exemple entre projets — joignez deux bases que vous possédez et ajoutez le résultat à une troisième :
-- Join two projects you own and append the result to a third. INSERT INTO warehouse.public.customer_orders SELECT o.id, o.amount, c.segment FROM shop.public.orders o JOIN crm.public.customers c ON c.id = o.customer_id WHERE o.created_at >= now() - interval '1 day';
Un simple SELECTqui n'écrit rien reste valide; son résultat est journalisé sous forme d'aperçu, puis ignoré. Si un résultat n'est pas capturé par le SQL, il est perdu — comme une requête à l'invite d'une base de données.
En créer une
Allez à Calcul → Requêtes planifiées → Nouvelle requête planifiée et remplissez trois champs : un nom, le SQL et une planification. C'est tout le formulaire.
La planification
Les planifications utilisent le cron standard à 5 champs — minute heure jour-du-mois mois jour-de-semaine — et toutes les heures sont en UTC. Le sélecteur propose le mode Simple (horaire / quotidien / hebdomadaire) ou une expression cron brute.
0 5 * * * # every day at 05:00 UTC 0 * * * * # every hour, on the hour */30 * * * * # every 30 minutes 0 6 * * 1 # every Monday at 06:00 UTC
Exécutions, historique et annulation
Ouvrez une requête pour voir son historique d'exécution — chaque exécution est Réussie, Échouée, Délai dépassé ou Annulée. Vous pouvez Exécuter immédiatement pour tester sans attendre le prochain déclenchement, Suspendre puis reprendre une requête, et annuler une exécution encore en file ou en cours. Chaque exécution est bornée par un délai; une requête trop longue est enregistrée comme un délai dépassé.
L'isolation d'une exécution
Chaque exécution s'effectue dans un moteur SQL isolé, en mémoire, avec un plafond de mémoire et un délai par exécution, et avec l'accès au système de fichiers local désactivé— une requête peut atteindre vos bases Postgres par le réseau, mais ne peut ni lire ni écrire de fichiers sur l'hôte. Elle ne voit que les bases que votre propre compte possède; les données d'un autre client ne sont jamais accessibles. Tout s'exécute à Montréal; rien de la requête ni de ses résultats ne quitte le Canada.
Forfaits
Les requêtes planifiées sont offertes sur tous les forfaits. Les forfaits diffèrent par la priorité d'exécution — au meilleur effort sur Démarrage, prioritaire sur Live, capacité dédiée sur Dédié. Voir Forfaits et limites. Pour plutôt explorer ou transformer des fichiers téléversés en SQL, voir Atelier de données.