Get, set, delete
Importațikv din twenty-sdk/logic-function. Valorile pot fi orice payload serializabil JSON.
src/logic-functions/sync-linear-issues.ts
Domenii de aplicare
Fiecare intrare are un domeniu de aplicare, transmis ca opțiune la fiecare apel. Valoarea implicită esteWORKSPACE.
WORKSPACE(implicit) — intrarea este privată pentru instalarea curentă a workspace-ului aplicației tale. Fiecare workspace care instalează aplicația primește propriul set independent de chei. Aceasta este opțiunea potrivită pentru cache-uri, cursoare și stare specifică fiecărui workspace.SERVER— intrarea este partajată între fiecare instalare a aplicației tale de pe server. Intrările de tip server se comportă ca niște claim-uri: valoarea stocată este întotdeauna workspaceId-ul care a revendicat cheia (omitevaluelasetpentru a revendica cheia pentru workspace-ul curent), iar doar acel workspace o poate suprascrie sau șterge. Orice instalare poate citi intrarea.
kv.set aruncă o eroare atunci când cheia este deja revendicată de un alt workspace.
Folosește-l: păstrează în cache un apel costisitor
O utilizare tipică este păstrarea în cache a unui răspuns lent sau cu limitare de rată de la un terț, astfel încât rulările repetate să îl refolosească în loc să plătească costul de fiecare dată.src/logic-functions/getExchangeRate.logic-function.ts
Tipare și sfaturi
- Spații de nume. Prefixează cheile pentru a păstra domeniile diferite separate —
sync-cursor:linear,cache:exchange-rate:USD:EUR,lock:nightly-report. - Expiry (TTL). Store-ul nu are expirare integrată. Stochează un timestamp în interiorul valorii (ca în exemplul de cache) și verifică-l la citire sau curăță cheile învechite dintr-o funcție declanșată de cron.
- Ce să stochezi. Orice valoare serializabilă JSON — numere, stringuri, array-uri, obiecte. Păstrează intrările mici; acesta este pentru coordonare și caching, nu pentru blob-uri mari sau fișiere. Pentru fișiere, folosește un câmp
FILESșiuploadFile. - Vizibilitate. Intrările există în baza de date a instanței, nu ca înregistrări ale workspace-ului — nu apar niciodată în interfața workspace-ului, nu fac parte din modelul de date al aplicației tale și nu necesită permisiuni de rol sau de obiect.
Alternativă: un obiect de stocare interogabil
Spațiul de stocare integrat este, în mod deliberat, opac: intrările nu sunt înregistrări, astfel că nu le poți răsfoi în UI, nu le poți corela cu alte obiecte și nu le poți filtra cu interogări de înregistrări. Când ai nevoie de oricare dintre acestea — de exemplu un jurnal de sincronizare vizibil sau o stare per-înregistrare — definește în schimb un mic obiect tehnic cu un câmpkey unic și un câmp RAW_JSON value, și interoghează-l prin clientul API tipizat. Vezi Objects pentru referința defineObject și Data → Unique indexes pentru aplicarea unicității cheilor.
- Limitarea la o înregistrare. Adaugă o relație de la obiectul de stocare la obiectul țintă, în loc să codifici id-ul în cheie.
- Vizibilitate și permisiuni. Rândurile trăiesc în baza de date a workspace-ului ca orice altă înregistrare, astfel încât pot fi interogate prin API și respectă rolul aplicației tale. Pentru a ține store-ul în afara UI-ului principal, nu îl include în navigation menu.
Spre deosebire de spațiul de stocare integrat, un obiect personalizat este întotdeauna limitat la un singur workspace — nu poate partaja intrări între instalări, așa cum fac cheile
SERVER.