store() déclare un store, depuis n’importe quel fichier de src/, et le nom de son export est le nom du store. Il prend un objet, StoreConfig, ou rien.
src/warnings.ts
Comment utiliser un store, où sont ses données et comment marche l’expiration est dans le guide. Cette page liste ce qui existe.
store()
src/ : le nom de l’export est le nom du store, et de son fichier dans data/ (ou de ses clés dans Redis, avec storage: 'redis'). Par serveur sauf si scope: 'global' est donné, avec une expiration si expires l’est.
StoreConfig
Ce qu’un fichier donne àstore().
'guild' (le défaut) : les données sont gardées par serveur, et une fonction qui tourne dans un serveur lit et écrit les données de ce serveur, sans rien dire. 'global' : un seul jeu de données pour tout le bot.Où les données sont gardées :
'file' (le défaut), un fichier dans le dossier data/ du projet, ou 'redis', le Redis de REDIS_URL dans .env. Seuls les stores qui disent 'redis' y écrivent quelque chose.Combien de temps une valeur est gardée, sauf si
set() dit autrement : un nombre et une unité, s, m, h ou d, comme '10m', '1d' ou '1h30m'. Gardée pour toujours par défaut.StoreScope
StoreStorage
storage de sa config nomme.
Store
Ce que renvoiestore() : une déclaration que le framework trouve dans les exports d’un fichier. C’est un ScopedStore pour le serveur où le code tourne, plus :
in()
ScopedStore
Un store, lu et écrit pour un serveur ou pour tout le bot.get()
key, ou undefined quand il n’y en a pas, ou qu’elle a expiré.
set()
value à key. La valeur doit être du JSON : pas de Date, de Map ni d’instance de classe.
update()
key et garde ce que renvoie change, d’un trait : rien de ce qui est écrit entre-temps n’est perdu, même par un autre processus. change reçoit undefined quand il n’y a pas encore de valeur, et peut tourner de nouveau quand la valeur a changé entre-temps : gardez-le un simple calcul. L’expiration reste ce qu’elle était, sauf si options dit autrement.
increment()
by (1 par défaut, négatif pour retirer) au nombre à key, en partant de 0, d’un trait comme update(), et renvoie le nouveau nombre. Seulement pour un store de nombres.
delete()
key. true quand il y en avait une.
getMany()
undefined pour une clé qui n’en a pas.
setMany()
options. Chaque valeur est vérifiée avant que rien ne soit écrit.
deleteAll()
prefix, ou chaque valeur du store (du serveur, pour un store par serveur) sans préfixe. Renvoie combien il y en avait.
entries()
prefix, sans ordre particulier. Les expirées sont laissées de côté.
ttl()
key est encore gardée, en millisecondes : null quand elle est gardée pour toujours, undefined quand il n’y a pas de valeur.
StoreKey
[channel.id, message.id]), qu’entries() peut ensuite lister par préfixe.
StoreSetOptions
Ce queset() et update() prennent en plus de la valeur.
Combien de temps la valeur est gardée : une durée comme
'10m', une Date, ou null pour la garder pour toujours. L’expires du store par défaut.StoreEntry
Une entrée d’un store, commeentries() les liste.
La clé, chacune de ses parties (le serveur laissé de côté pour un store par serveur).
Où vivent les données
Un fichier par store,data/<nom>.json à la racine du projet : { "version": 1, "entries": [[key, value, expiresAt], ...] }, avec expiresAt en millisecondes depuis l’epoch ou null. Écrit peu après un changement, d’un seul bloc (un fichier temporaire, puis un renommage), et quand le bot s’arrête. Les entrées expirées sont retirées quand le fichier est lu, quand on les demande, et chaque minute.
En production sur plusieurs processus, le processus que vous avez lancé garde les données et répond aux autres par IPC.
Avec storage: 'redis', une clé Redis par valeur : <nom>:<partie>:<partie> (l’id du serveur est la première partie d’un store par serveur ; :, *, ?, [, ], \ et % dans une partie s’écrivent %XX), sa valeur le JSON de la valeur, son expiration posée sur la clé (PX), pour que Redis l’oublie seul. chapterjs dev met dev: devant chaque clé. entries() est un SCAN sur le préfixe. Chaque processus atteint Redis lui-même. update() et increment() sont une transaction (WATCH, MULTI, EXEC), refaite sur la nouvelle valeur quand un autre processus a écrit la clé entre-temps, sur une connexion à elles (4 au plus à la fois par processus, en plus de la principale) ; les mises à jour d’une même clé dans un processus s’attendent l’une l’autre. L’adresse vient de REDIS_URL et REDIS_PASSWORD (voir la référence du CLI) ; un Redis qui ne répond pas arrête dev et start avant d’atteindre Discord, et la connexion revient d’elle-même une fois qu’elle a été faite.