Skip to Content


Index Odoo sur : x_status, x_scheduled_at, x_channel, x_event_type → pour que les batchs n8n restent rapides.

Pourquoi indexer ces champs ?

Sur un modèle comme x_synergia_notification qui peut vite monter à des centaines de milliers de lignes, les batchs n8n vont faire en boucle des recherches du type :

  • “toutes les notifs pending à envoyer maintenant ou avant maintenant, par canal X et type Y”.

Sans index, chaque requête = scan complet de la table → ça rame, surtout en SaaS.

D’où l’intérêt d’indexer :

  • x_status
  • x_scheduled_at
  • x_channel
  • x_event_type

🔹 Concrètement dans Odoo (via Studio)

Dans Odoo Studio, pour chaque champ :

  1. Ouvrir le modèle x_synergia_notification.
  2. Cliquer sur le champ (ex. x_status).
  3. Onglet Propriétés techniques.
  4. Cocher “Indexé” (ou équivalent selon version).

À faire pour :

  • x_status (sélection)
  • x_scheduled_at (datetime)
  • x_channel (sélection)
  • x_event_type (sélection)

👉 Même si Odoo ne fait pas de composite index (multi-colonne) via Studio, quatre index simples sur ces colonnes suffisent pour 99 % des requêtes qu’on fera depuis n8n.

🔹 Exemple de requête côté n8n / API Odoo

Typiquement, votre node “HTTP Request → Odoo” cherchera :

{
  "model": "x_synergia_notification",
  "method": "search_read",
  "args": [
    [
      ["x_status", "=", "pending"],
      ["x_scheduled_at", "<=", "2025-12-08 10:00:00"],
      ["x_channel", "in", ["sms", "rcs"]],
      ["x_event_type", "in", ["rappel_rdv", "prevention"]]
    ],
    ["id", "x_status", "x_scheduled_at", "x_channel", "x_event_type", "x_payload"],
    0,
    100,
    "x_scheduled_at"
  ]
}

Grâce aux index sur ces champs, Odoo/PostgreSQL peut :

  • filtrer d’abord sur x_status + x_scheduled_at,
  • affiner avec x_channel + x_event_type,
  • renvoyer les 100 prochaines notifs à traiter sans scanner toute la table.