Draairesultaten opslaan

Pivots & enrichment eindigt met een ingest: de gekozen kandidaten staan op het canvas, getagd met de spil die hen bracht, en nergens anders. save is de stap terug — de pivot schrijft zijn eigen resultaten naar het systeem waar ze vandaan komen, en de bibliotheek bewaart de boeken over wat er is gepasseerd.

summarize  →  fetch  →  triage  →  ingest  →  save
  "2,143"     the 210    the 12    on canvas   in the source system

De bibliotheek schrijft nooit zelf ergens en heeft geen inloggegevens. Wat het bijdraagt is de boekhouding – welke elementen een run heeft gecreëerd, of ze zijn geschreven, welke mislukt, en wat een nieuwe poging zou moeten opleveren – want dat is het deel dat alleen het weet.

Eén declareren

const objects = {
    id: 'objects',
    label: 'Objects & attributes',
    fetch: (nodes, narrowing, ctx) => api.objects(nodes[0].id, { signal: ctx.signal }),

    save: async ({ origin, nodes, children, edges }, ctx) => {
        const written = await api.createObjects(origin[0].id, [...nodes, ...children], {
            signal: ctx.signal,
        })
        return {
            savedNodeIds: written.ok.map(o => o.localId),
            savedEdgeIds: edges.map(e => e.id),
            canonicalIds: Object.fromEntries(written.ok.map(o => [o.localId, o.uuid])),
            message: written.failed.length ? `${written.failed.length} refused` : undefined,
        }
    },
}

De payload bestaat uit live-grafiekobjecten, niet uit onbewerkte fragmenten:

Veld	Wat het bevat
origin	waarop de spil werd uitgevoerd - "aan welke gebeurtenis is dit gekoppeld"
nodes	de knooppunten die deze run heeft gemaakt
children	inhoud van de container met toegevoegde uien, afgevlakt; elk bereikbaar vanuit de container via parentNode
edges	de randen die deze run creëerde
vouched	wat er vóór deze run al op het doek stond
attempt	1 de eerste keer, hoger bij een nieuwe poging

Laat save weg en de resultaten van de pivot zijn niet op te slaan. Ze komen nooit in het grootboek terecht, maar nooit geteld als ze niet zijn opgeslagen, en er verschijnt geen Save voor hen. Dat is de juiste verklaring voor a draai over afgeleide gegevens – de uitvoer van een correlatie-engine is niet van jou om terug te schrijven – en dat wel is wat een permanente "210 unsaved" zonder remedie tegenhoudt.

Wat je retourneert

Teruggegeven	Betekent
undefined / true	de hele lading is geschreven
false, of gooien	niets daarvan was; de fout bereikt de nieuwe poging
{ savedNodeIds, savedEdgeIds }	een gedeeltelijke schrijfbewerking — alles wat geen naam heeft, blijft niet opgeslagen
{ canonicalIds }	id het toegewezen bronsysteem, ingetoetst door de lokale id
{ message }	woordelijk weergegeven in de resultaattoast
{ cancelled: true }	de analist trok zich terug: niets opgenomen, geen toast, geen poging

savedNodeIds omvat nodes en children samen. Een id die een element een naam gaf tijdens deze run not create wordt genegeerd: een pivot schrijft nooit wat hij niet heeft geproduceerd en kan dit dus ook niet rapporteren ook geschreven.

Een save die een geschreven rand rapporteert, maar niet de knooppunten die ermee zijn verbonden, wordt voor de nominale waarde genomen. Wat het bronsysteem zegt te hebben geschreven, mag de bibliotheek niet terzijde schuiven.

Vraag het eerst aan de analist

Soms heeft een schrijven één antwoord nodig voordat het kan worden uitgevoerd, bijvoorbeeld welke relatie elk met elkaar verbindt resultaat naar het knooppunt waaruit het is verrijkt. ctx.promptData opent de eigen modal van de bibliotheek, met dezelfde opties als die achter het maken van knooppunten en randen: declaratief fields, of render + getValues voor je eigen HTML. Het wordt opgelost naar de waarden, of null bij annuleren.

save: async (payload, ctx) => {
    const answer = await ctx.promptData({
        fields: [{ key: 'relationship', label: 'Relationship', type: 'text', defaultValue: 'related-to' }],
    })
    if (!answer) return { cancelled: true }
    await api.attach(payload, answer.relationship, { signal: ctx.signal })
},

De modal heeft de titel en wordt ingediend met Opslaan tenzij title en submitLabel zeggen anders. Als u { cancelled: true } retourneert, blijft de run precies zoals deze was vóór de klik: nog steeds niet opgeslagen, geen toast, geen nieuwe poging, en de volgende poging is nog steeds attempt: 1. Een redding over meerdere runs stopt bij de eerste annulering, en het rapport telt dit onder cancelled in plaats van als een mislukking. Bij een geannuleerde nieuwe poging wordt de toast teruggezet zoals hij was.

Alleen een opgeslagen bestand waarop iemand heeft geklikt, kan vragen. Opslaan in het Draaipaneel, Opslaan en in een Review-paneel de herkansingspas van de toast interactive: true; autoSave en een gewone graph.pivots.save() wel niet, dus hun promptData lost null in één keer op zonder dat er iets is getekend. Een host met een Save knop op zichzelf passeert ook de vlag:

await graph.pivots.save(undefined, { interactive: true })

Er wordt om één gevraagd

await graph.pivots.save()          // every savable run with something still unsaved
await graph.pivots.save(runId)     // one run
await graph.pivots.save(pivotId)   // every unsaved run of one pivot

graph.pivots.unsaved()             // the runs still waiting
graph.pivots.unsavedCount()        // { nodes, edges } — exact, not advisory
graph.pivots.unsavedCount(pivotId) // one pivot's share of it
graph.pivots.isSaved(node)         // false for the unsaved *and* the not-savable
graph.pivots.isSavable(node)       // which of those two it is

Onderdeel van een run

const selected = graph.renderer.getGraphInteraction().getSelectedNodeIDs() ?? []
await graph.pivots.save({ elements: selected })   // Nodes, Edges or their ids

Elke run waarbij een van de genoemde elementen is gemaakt, wordt één keer gevraagd, met een beperkte payload wat werd genoemd. Een benoemd knooppunt brengt de in behandeling zijnde kinderen eronder, en er ontstaat een rand wanneer het ene uiteinde wordt genoemd en het andere ook wordt genoemd of niet ongeschreven blijft: de oorsprong, een knooppunt dat al is opgeslagen, alles waar het grootboek niet op wacht. Een voorsprong op een in behandeling zijnde Het weggelaten knooppunt blijft erbij achter, dus een schrijfactie stuurt nooit een regel naar niets. Genoemd elementen waarop niets wacht, worden genegeerd en de oproep krijgt één toast voor elke uitvoering ervan vroeg.

De rest blijft in behandeling en telt. Opnieuw proberen en canonicalIds werken zoals ze dat voor een geheel doen rennen. Een run wordt pas in de geschiedenis gemarkeerd als er niets meer van te schrijven is. isSavable(el) en isSaved(el) geven aan of een menu-item zoals Selectie opslaan alles te doen.

Uitvoeringen worden één voor één uitgevoerd en elke uitvoering wordt alleen verzonden wat nog niet is opgeslagen, dus een nieuwe poging is hetzelfde bel. Het resultaat komt als een toast: Saved 12 nodes, of Saved 9 of 12 met een Opnieuw proberen die dezelfde toast overneemt in plaats van een tweede te stapelen.

In de gebruikersinterface staan de telling en de knop onderaan het draaipaneel en een beoordelingsvenster draagt het aandeel van zijn eigen provider in zijn header. Er verschijnt niets terwijl het getal nul is.

Beiden schrijven alles in behandeling, zonder een keuze te kunnen maken. Een applicatie die besparing biedt ergens anders, zoals een item Geselecteerde opslaan in het knooppuntmenu, kunnen ze worden uitgeschakeld:

new Pivotick(el, data, { pivots: [objects], pivotSaveControls: false })
graph.pivots.saveControls = true   // and back, at runtime

Alleen de twee bedieningselementen gaan. Het grootboek, de tellingen, save(...), de toast en het opnieuw proberen, en canonicalIds werk zoals voorheen.

autoSave: true schrijft elke run op het moment dat deze landt, zonder gebaar. Het loopt achter de ingest wordt opgelost in plaats van erin, zodat een langzame backend het canvas nooit omhoog houdt, en a storing meldt via de melder en laat de gegevens staan waar ze zijn. Koppel het met autoIngest: true voor een draaipunt dat van begin tot eind hands-off is — een gebeurtenis uitbreiden naar objecten die al eigendom zijn van de bron.

Ideert het bronsysteem

Door op te slaan ontstaat er meestal iets, en het gemaakte ding krijgt meestal een ID van de bron systeemkeuze, niet degene die uw provider gebruikte toen deze kandidaat was. Morgen hardlopen retourneert vervolgens dezelfde objecten onder ids die dedup niet herkent, en de analist krijgt er twaalf duplicaten van wat ze gisteren hebben bewaard.

Retourneer canonicalIds en de bibliotheek behoudt de alias. Ingest dedup, de kindervakbond en randeindpunten raadplegen het allemaal, dus de herhaling zegt in plaats daarvan 12 al op canvas.

graph.pivots.canonicalId(node)   // 'a1b2…' — the id the source assigned

Waarom het knooppunt de ID behoudt waaronder het is geland

Opnieuw intoetsen zou reiken tot randen, clusters, selectie, de query-engine, herkomst en de geschiedenis, voor een voordeel dat de alias al levert waar het er toe doet. De eerlijke kosten: graph.getNode(canonicalId) mist nog steeds, en canonicalId() is de lezing die dat niet doet.

Ongedaan maken bereikt het bronsysteem niet

Als u een opgeslagen run ongedaan maakt, worden de knooppunten van het canvas verwijderd. Er wordt niet iets uit verwijderd het systeem waarnaar ze zijn geschreven, en de bibliotheek geeft geen compenserende schrijfbewerkingen uit: a lokale weergave is geen transactie tussen twee systemen.

De geschiedenis zegt dit in plaats van het aan jou over te laten: een gemarkeerde run is doorgeschreven gechipt saved, en de voettekst van het menu telt wat een bereik achterlaat. PivotRun heeft een telling van saved voor een oppervlak dat vóór de klik wil waarschuwen. Zie Ongedaan maken en geschiedenis voor hoe het een persistente invoer behandelt.

Een mislukte redding raakt ook nooit het canvas. De analist accepteerde deze twaalf knooppunten; een weigering van de backend is informatie over de backend, niet een omkering van hun beslissing. Zij blijf, blijf niet opgeslagen en blijf opnieuw probeerbaar.

Niet-opgeslagen knooppunten markeren

new Pivotick(el, data, { pivots: [objects], pivotMarkUnsaved: true })

Plaatst een klasse pvt-node-unsaved op elk knooppunt dat door een run is gemaakt en niet is teruggeschreven een stylesheet kan dit overnemen; de standaardwaarde is een stippellijn. Standaard uitgeschakeld, en liever een klasse dan een randbadge: een knooppunt heeft vier randhoeken en slechts twee als het kinderen heeft, en a Een marker die een aangegeven potentieel van de rand duwt, kost meer dan het zegt.