Obtenir, définir, supprimer
Importezkv depuis twenty-sdk/logic-function. Les valeurs peuvent être n’importe quelle charge utile sérialisable en JSON.
src/logic-functions/sync-linear-issues.ts
Périmètres
Chaque entrée possède une portée, passée comme option à chaque appel. La valeur par défaut estWORKSPACE.
WORKSPACE(par défaut) — l’entrée est réservée à l’installation actuelle de votre application dans l’espace de travail. Chaque espace de travail qui installe l’application obtient son propre ensemble indépendant de clés. C’est ce qu’il vous faut pour les caches, les curseurs et l’état par espace de travail.SERVER— l’entrée est partagée entre toutes les installations de votre application sur le serveur. Les entrées serveur se comportent comme des revendications : la valeur stockée est toujours le workspaceId qui a revendiqué la clé (omettrevaluelors desetpour revendiquer la clé pour l’espace de travail actuel), et seul cet espace de travail peut la remplacer ou la supprimer. N’importe quelle installation peut lire l’entrée.
kv.set lève une exception lorsque la clé est déjà revendiquée par un autre espace de travail.
Utilisez-le : mettez en cache un appel coûteux
Un cas d’utilisation typique consiste à mettre en cache une réponse tierce lente ou soumise à des limites de débit afin que les exécutions répétées la réutilisent au lieu d’en payer le coût à chaque fois.src/logic-functions/getExchangeRate.logic-function.ts
Modèles et conseils
- Espaces de noms. Préfixez les clés pour séparer les différentes préoccupations —
sync-cursor:linear,cache:exchange-rate:USD:EUR,lock:nightly-report. - Expiration (TTL). Le store n’a pas d’expiration intégrée. Stockez un horodatage dans la valeur (comme dans l’exemple de cache) et vérifiez-le à la lecture, ou effacez les clés obsolètes à partir d’une fonction déclenchée par cron.
- Que stocker. Toute valeur sérialisable en JSON — nombres, chaînes de caractères, tableaux, objets. Gardez les entrées petites ; ceci sert à la coordination et à la mise en cache, pas aux blobs volumineux ni aux fichiers. Pour les fichiers, utilisez un champ
FILESetuploadFile. - Visibilité. Les entrées résident dans la base de données de l’instance, et non comme enregistrements d’espace de travail — elles n’apparaissent jamais dans l’interface utilisateur de l’espace de travail, ne font pas partie du modèle de données de votre application et ne nécessitent aucun droit ni aucune permission d’objet.
Alternative : un objet de stockage interrogeable
Le magasin intégré est délibérément opaque : les entrées ne sont pas des enregistrements, vous ne pouvez donc pas les parcourir dans l’interface utilisateur, les relier à d’autres objets, ni les filtrer avec des requêtes sur les enregistrements. Lorsque vous avez besoin de tout cela — par exemple un journal de synchronisation visible, ou un état par enregistrement — définissez plutôt un petit objet technique avec un champkey unique et un champ RAW_JSON value, puis interrogez-le via le client d’API typé. Consultez Objets pour la référence defineObject et Données → Index uniques pour faire appliquer l’unicité des clés.
- Délimiter la portée à un enregistrement. Ajoutez une relation de l’objet de stockage vers l’objet cible plutôt que de coder l’identifiant dans la clé.
- Visibilité et autorisations. Les lignes résident dans la base de données de l’espace de travail comme n’importe quel autre enregistrement, elles sont donc interrogeables via l’API et respectent le rôle de votre application. Pour garder le store hors de l’interface principale, ne l’ajoutez pas à votre menu de navigation.
Contrairement au magasin intégré, un objet personnalisé est toujours limité à un seul espace de travail — il ne peut pas partager des entrées entre installations comme le font les clés
SERVER.