Live och headless

Vid varje anrop letar servern efter en editor som har dokumentet, via de låsfiler som editorerna har i ~/.erd-editor/ide/. Varje VS Code-fönster och varje valvfönster i Obsidian med ERD Editor har en, och en JetBrains-IDE har en för hela IDE:n, som listar varje projekt som är öppet i den. En editor tar bort sin låsfil när den stängs. Det som servern hittar avgör vart redigeringen går.

Vad den hittar	Vad en redigering gör
En editor vars arbetsområde, valv eller öppna projekt innehåller dokumentet, eller som har det öppet	Live. Öppnar dokumentet i ERD Editor vid behov, ansluter till redigeringssessionen och tillämpar ändringen där. Redigeringarna visas direkt och sparas på samma sätt som editorn sparar dina egna – se Spara.
Ingen editor	Headless. Läser in filen, tillämpar ändringen och ersätter filen innan den svarar, så resultatet anger saved: true och erd_save har ingenting att göra.
En editor med hubben avstängd	Nekad. Läsningar fungerar fortfarande, från disken. En ändring som skrivs till filen medan en editor har den öppen kan skrivas över när editorn sparar nästa gång, så servern skriver ingenting.
En editor vars hubb är på men som använder ett annat protokoll än serverns: med servern i version 1.0.0 eller senare ett VS Code-tillägg 3.x, ett Obsidian-plugin 0.x eller ett JetBrains-plugin 0.9.0 eller 0.10.0; med en server före 1.0.0 tillägget 4.0.0 eller senare, eller ett plugin 1.0.0 eller senare	Nekad, även för läsningar, med protocolMismatch. Meddelandet anger vilken sida som ska uppdateras: tillägget eller pluginet, eller servern – se Uppdatera.
En editor i Windows som har dokumentet under en annan sökväg till samma fil: agenten angav det via en nätverksresurs eller en mappad enhet på den här datorn, som \\localhost\C$\…, och editorn har det under dess enhetssökväg, eller tvärtom	Nekad, även för läsningar, med invalidPath. Meddelandet anger den sökväg som editorn har dokumentet under; anropa igen med den sökvägen.
En editor i Windows som Windows håller agenten borta från: en som startades som administratör men inte agenten, eller vilken editor som helst när agenten körs i en sandlåda	Nekad, även för läsningar, med hubUnreachable och ett meddelande som anger varför. Kör editorn och agenten med samma behörigheter, till exempel genom att starta editorn igen utan administratörsbehörighet.

Resultatet av en redigering anger vilket läge den kördes i, live eller headless, och en nekad redigering anger varför. Sökningen görs på nytt vid varje anrop, så när en editor öppnas eller stängs följer nästa anrop med.

När mer än en editor har dokumentet vinner en som har det öppet över en som bara betjänar en mapp som innehåller det, och bland dem som betjänar en mapp vinner den vars mapp ligger djupast. Vid oavgjort, som när två editorer båda har det öppet, går dokumentet till den vars låsfil ändrades senast. Ett dokument i ett Obsidian-valv inuti en arbetsområdesmapp i VS Code går alltså till Obsidian, om inte VS Code har det öppet och Obsidian inte har det.

Anrop mot ett och samma dokument körs ett i taget, i den ordning de nådde servern. Anrop mot olika dokument körs parallellt.

Live

Agenten ansluter till editorn som ytterligare en medarbetare. Dess redigeringar når direkt varje editor som har dokumentet öppet, och dess fokus ritas ut på tabellen och cellen som den redigerar, precis som en medarbetares – se focusTracker.

En läsning öppnar aldrig en editor. En redigering öppnar dokumentet i ERD Editor när det ännu inte är öppet, utan att ta tangentbordsfokus.

En editor med ett VS Code-tillägg före 4.2.0, eller ett Obsidian- eller JetBrains-plugin före 1.2.0, tar fortfarande emot agentens redigeringar live, men den varken visar eller behåller de logiska namn, domänkopplingar och rader i ordlistorna som agenten skriver – se Uppdatera.

Med VS Code-tillägget 4.3.0 eller senare, eller Obsidian- eller JetBrains-pluginet 1.3.0 eller senare, avslutar en import i läget replace, och ett erd_undo eller erd_redo av en sådan, en relation som du ritar i editorn, oavsett serverns version – se Skapa relationer. Före de versionerna förblev ritandet aktivt, och ett klick på en tabell kunde lägga till en relation från en tabell som inte längre fanns i diagrammet. En import i läget append lämnar ritandet aktivt. En redigerare för en anteckning, ett tabellgruppsnamn eller en cell som du har öppen förblir öppen så länge diagrammet fortfarande innehåller och visar det som den redigerar.

Redigeringar som görs samtidigt

Med server 1.2.0 eller senare och, i editorn, VS Code-tillägget 4.3.0 eller senare eller Obsidian- eller JetBrains-pluginet 1.3.0 eller senare slutar redigeringar som du och agenten gör av samma sak samtidigt lika i editorn, i filen som den sparar och i det som erd_list, erd_get och erd_read ger agenten. Det gäller ett namn eller ett annat fält i en tabell, kolumn, relation, index, anteckning, tabellgrupp eller ordlisterad, databasnamnet och skripten före och efter tabellerna, samt positionen eller storleken på en tabell, anteckning eller tabellgrupp, men inte en färg, ordningen på kolumnerna i en tabell eller ett index, eller databasen. Två redigeringar av samma namn eller fält, två flyttar eller två storleksändringar slutar på den ena av de två, aldrig en blandning: en redigering som görs efter att den andra har nått sin sida vinner, och av två som görs i exakt samma ögonblick vinner en, samma på varje sida, oavsett vilken som kommer först.

Två färgändringar av samma tabell, anteckning eller tabellgrupp som görs samtidigt, som din och agentens erd_change_table_color, kan sluta olika, eller till och med ombytta, eftersom varje sida behåller den färg den hörde sist. En omordning av kolumner, din eller agentens erd_move_column eller erd_move_index_column, tillämpas på varje sida i den ordning den kommer, så två som görs samtidigt i en tabell eller ett index kan lämna dess kolumner i olika ordning. En ändring av databasen, din eller agentens erd_set_database, tillämpas också i den ordning den kommer, så två som görs samtidigt kan lämna editorn och agenten på olika databaser.

Din dragning och agentens erd_move_table, erd_move_tables, erd_move_memo, erd_move_table_group och erd_sort_tables skickas som de punkter de slutar på, så två flyttar av samma tabell, anteckning eller tabellgrupp slutar där en av dem placerade den, aldrig på de två sammanlagda. erd_move_table_group skickar punkten för gruppen och för var och en av dess tabeller i en batch, som en dragning av gruppens namnlist gör. En storleksändring skriver positionen och storleken tillsammans, så en flytt och en storleksändring av samma anteckning eller tabellgrupp som görs samtidigt, som erd_resize_memo medan du drar den anteckningen, slutar på en rektangel på båda sidor: storleksändringens eller, när flytten vinner, flyttens punkt med storleksändringens storlek. En flytt under 20 pixlar, som inte ger något steg i ångrahistoriken, går också ut som den punkt den slutar på, så den kan vinna över den andra sidans flytt, vare sig det är en kort erd_move_table_group eller en kort dragning som du gör, som ett klick som knuffar en tabell några pixlar.

Äldre versioner ansluter fortfarande, eftersom server 1.2.0 talar hubbprotokoll 2, som 1.0.0 till 1.1.1 gör. Med en server före 1.2.0, eller ett tillägg före 4.3.0 eller ett plugin före 1.3.0, kan en flytt eller storleksändring av en tabell, anteckning eller tabellgrupp som görs samtidigt lämna editorn och agenten med olika positioner. En äldre editor skickar din dragning som det flyttade avståndet, och en server före 1.2.0 skickar erd_move_table_group på det sättet också. Den andra sidan adderar det avståndet till den punkt den håller. Den äldre sidan tillämpar också den andra sidans punkter i den ordning de kommer. Agenten läser och redigerar då från sin egen position för den tabellen, anteckningen eller tabellgruppen, inte den som editorn visar och sparar. Det varar tills en senare flytt av den skickas som en punkt, som din dragning i en nyare editor eller agentens erd_move_table, eller tills agenten ansluter till dokumentet igen, som efter att editorn har kopplat bort den eller efter 30 minuter utan något anrop på dokumentet. Bortsett från en färg, kolumnordningen och databasen slutar ett namn eller ett annat fält som ändras samtidigt ändå lika när bara en sida är äldre, nästan alltid på den nyare sidans redigering. Med båda sidorna äldre kan de två fortfarande sluta olika.

Inget av detta gäller en headless-redigering, som skriver filen på egen hand.

Spara

Varje editor sparar agentens redigeringar på samma sätt som den sparar dina egna.

I VS Code markerar agentens redigeringar fliken som ändrad precis som dina egna, och de når disken först när dokumentet sparas. erd_save sparar det via VS Code, på samma sätt som sparkommandot i VS Code gör. Du kan spara i stället, med Ctrl + S (Windows/Linux) eller ⌘ + S (Mac). Om du stänger editorn med osparade redigeringar från agenten tillfrågas du om de ska sparas, som för alla andra osparade ändringar.

Obsidian sparar agentens redigeringar ungefär två sekunder efter att redigeringen upphör, och när fliken stängs sparas de utan fråga. En JetBrains-IDE skriver dem en bråkdel av en sekund efter att redigeringen upphör, och när fliken stängs skrivs det som fortfarande väntar; fliken visas aldrig som ändrad. I båda skriver erd_save dem direkt.

erd_save väntar först i upp till två sekunder på att editorn ska ha varje redigering som agenten har gjort. Det nekas med notSaved när editorn inte kunde bekräfta det, eller inte skrev filen: VS Code låter en flik förbli osparad när filen har ändrats på disken, och en JetBrains-IDE kunde inte skriva den, till exempel medan en dialogruta var öppen eller när det inte går att skriva till filen.

I VS Code och en JetBrains-IDE lyckas erd_save för ett dokument som inte har något kvar att spara, och filen lämnas som den är. Så är det när varje redigering har sparats, vilket en JetBrains-IDE gör på egen hand, och det fortsätter att gälla medan varje senare ändring är en som ett lås håller utanför filen, som att rulla eller zooma när Viewport är låst, byta flik när Canvas Type är låst eller byta namnvisning när Name View är låst. Alla lås är på som standard. En fil som en JetBrains-IDE inte kan skriva till nekas även då.

När editorn stänger dokumentet efter agentens senaste redigering får agentens nästa anrop en notering om att de redigeringarna bara finns i filen om de sparades innan editorn stängdes.

Ångra

erd_undo ångrar den senaste redigeringen som agenten gjorde, aldrig dina, och erd_redo tillämpar den igen. Editorns eget kommando Ångra fungerar tvärtom: det ångrar dina redigeringar och aldrig agentens, eftersom ändringar som kommer från en annan editor inte registreras i din historik.

Några redigeringar skapar inget steg i editorns ångrahistorik: erd_set_database och erd_set_database_name bland inställningsverktygen, samt erd_resize_memo. Det gör inte heller ett anrop till erd_move_table_group som flyttar gruppen mindre än 20 pixlar totalt, vågrätt och lodrätt sammanlagt, även om gruppen stannar kvar där den flyttades. Ett anrop som inte ändrar något skapar inte heller något steg: erd_set_column_primary_key, erd_set_column_unique, erd_set_column_not_null, erd_set_column_auto_increment, erd_set_index_unique eller erd_set_index_column_order som anger ett värde som dokumentet redan har; erd_add_index_column med en kolumn som redan finns i indexet; erd_set_table_group med tabeller som redan finns i den gruppen (eller som redan saknar grupp, med groupId null); erd_move_table_group till den punkt där gruppen redan står; erd_resize_table_group till den rektangel som gruppen redan har; erd_sort_tables på ett dokument utan tabeller; erd_set_table_logical_name eller erd_set_column_logical_name med det logiska namn som tabellen eller kolumnen redan har, när en härledning från det inte skulle ändra något; erd_set_column_domain med den domän som kolumnen redan är kopplad till, när kolumnen redan har den domänens typ och Synkronisera datatyp i relationer inte skulle ändra typ på någon kolumn längs dess relationer; erd_update_word, erd_update_term eller erd_update_domain med bara värden som raden redan har, om inte name anges för en term som saknar fysiskt namn och termens ord bildar ett; erd_derive_physical_names när varje namn som anropet omfattar och som har ett logiskt namn redan har det som ordlistorna ger det och är märkt som härlett; eller en import med mode append som inte tillför någon tabell (för erd_import_json ingen tabell och ingen anteckning). erd_undo hoppar över dessa och nämner dem i sitt resultat. Andra redigeringar, som erd_change_relationship_type, erd_change_relationship_on_delete, erd_change_relationship_on_update, erd_change_table_group_name, erd_change_table_group_color och erd_set_ddl_script, skapar ett steg även när de anger ett värde som dokumentet redan har.

Agentens ångrahistorik upphör, med en notering i resultatet, när:

• Agenten ansluter till dokumentet igen, till exempel efter att editorn har kopplat bort agenten från det.
• Editorn avslutas, eller stänger dokumentet och slutar betjäna det, och agenten fortsätter att redigera filen på disken.
• En editor tar över ett dokument som agenten redigerade på disken.

Servern stänger också ett dokument som agenten inte har gjort några anrop mot på 30 minuter, och ångrahistoriken försvinner med det, utan någon notering.

När editorn försvinner

Så länge en editor har ett dokument går servern aldrig över till filen på eget initiativ. Om anslutningen bryts ansluter den igen. Först när editorn har avslutats, eller har stängt dokumentet och inte längre listar det eller en mapp som innehåller det, redigerar servern filen, och det framgår av resultatet. Det händer när du stänger ett diagram som ligger utanför alla mappar som editorn betjänar (i VS Code ett som har öppnats utanför arbetsområdet), när du slår av pluginet ERD Editor i Obsidian och när du stänger projektet som innehåller dokumentet i en JetBrains-IDE eller slår av pluginet där. Ett stängt diagram i en mapp som editorn betjänar stannar hos editorn, och agentens nästa redigering öppnar det igen.

En editor som fortfarande körs, men vars låsfil är borta och vars anslutning stängdes utan att den stängde dokumentet, nekar nästa redigering med hubGone. Meddelandet anger vad som frigör dokumentet: i VS Code läser du in det fönstret igen, eller stänger det så att agenten kan redigera filen direkt; i Obsidian slår du på pluginet ERD Editor igen, eller stänger det fönstret; i en JetBrains-IDE slår du på pluginet igen, eller avslutar IDE:n.

En läsning går i stället till filen på disken, med en notering om att redigeringar som ännu inte har sparats i editorn saknas, i två fall: när editorn som har dokumentet har hubben avstängd, och i fallet med hubGone ovan. En läsning som inte kan ansluta till en editors hubb nekas med hubUnreachable, precis som en redigering.

Headless

När ingen editor betjänar dokumentet läser varje redigering in filen, tillämpar ändringen och skriver tillbaka filen innan den svarar, så dess resultat anger saved: true – se Resultat. Skrivningen görs till en temporär fil bredvid dokumentet, med namnet .<name>.<id>.tmp, som sedan ersätter det, så att dokumentet aldrig blir halvskrivet, utom i Windows i fallet med skrivning på plats som beskrivs nedan.

Före det sista steget kontrollerar servern om filen har ändrats på disken under anropet. Om den har det skrivs ingenting, filen läses in igen och anropet nekas med conflict. Agenten anropar igen. En fil som har ändrats mellan två anrop läses helt enkelt in igen, och agentens ångrahistorik fram till dess rensas.

En skrivskyddad fil lämnas som den är, och redigeringen nekas med readonly: en fil utan skrivbehörighet för sin ägare, eller med skrivskyddsattributet i Windows, som en Perforce- eller TFVC-fil som inte är utcheckad. Gör den skrivbar och anropa sedan igen. Läsningar fungerar fortfarande.

Om en editor börjar betjäna dokumentet medan agenten redigerar det på disken nekas just den redigeringen med hubAppeared och ingenting skrivs. Nästa anrop redigerar via editorn.

I Windows gäller ytterligare två regler:

• Ett dokument med egna behörigheter, som skiljer sig från mappens, skrivs på plats i stället för att ersättas, så att det behåller dem, och den temporära filen tas bort efteråt. Ett program som läser dokumentet under den skrivningen kan hitta text som inte går att tolka.
• En fil som ett annat program håller öppen kan inte ersättas, så servern försöker igen i upp till två sekunder. Varje försök letar först efter en editor igen, och en editor som har börjat betjäna dokumentet under tiden nekar skrivningen med hubAppeared, eller med blocked när dess hubb är avstängd. Om filen fortfarande hålls öppen efter två sekunder skrivs ingenting, filen läses in igen och anropet misslyckas med ett meddelande som citerar systemfelet.

En server före 1.1.0 läser ett dokument utan dess logiska namn, kolumnernas domänkopplingar och dokumentets ord, termer och domäner, så den första redigering som den skriver till filen utelämnar dem. Uppdatera servern – se Uppdatera.

Nekad

Ett VS Code-fönster behåller sin låsfil även när dess hubb är avstängd: när dineug.erd-editor.agentHub.enabled är av, när arbetsområdet inte är betrott eller när dess hubb inte kunde lyssna. Ett valvfönster i Obsidian behåller sin låsfil med hubben avstängd när inställningen Coding agents är av och när dess hubb inte kunde lyssna. En JetBrains-IDE behåller sin låsfil med hubben avstängd när inställningen Coding agents är av, när dess hubb inte kunde lyssna och medan IDE:n avslutas.

En redigering av ett sådant dokument nekas med blocked, eftersom den öppna editorn kan skriva över en ändring som har skrivits till filen nästa gång den sparar. Läsningar fungerar fortfarande, från filen på disken.

För att låta agenten redigera slår du på hubben igen, så som meddelandet anger för den editorn: i VS Code litar du på arbetsområdet och slår på inställningen, eller läser in fönstret igen; i Obsidian slår du på Coding agents, eller läser in Obsidian igen; i en JetBrains-IDE slår du på Coding agents, eller startar om IDE:n om inställningen redan är på.

En JetBrains-IDE nekar också, med hubDisabled, att ändra ett dokument som bara ingår i projekt som den inte litar på. Agenter kan fortfarande läsa ett sådant dokument, och erd_list_documents listar det som readonly. Lita på projektet och anropa sedan igen.

En editor som inte har någon låsfil skyddar ingenting, och agenten redigerar filen på disken även när diagrammet är öppet där. Så är det för Obsidian eller en JetBrains-IDE som har installerats som Flatpak i Linux, en JetBrains-IDE utan JCEF och en JetBrains-IDE vars hubb inte kunde starta – se Konfigurera Obsidian och Konfigurera en JetBrains-IDE. Ett VS Code-tillägg före 3.0.0 och ett JetBrains-plugin före 0.9.0 har inte heller någon, eftersom de saknar hubb.

Dokument

Ett dokument anges med path, absolut eller relativ till serverns arbetskatalog.

• Nya dokument är .erd.json. erd_open_document med create skapar filen och lägger till .erd.json till ett namn som saknar filändelse. Precis som ett nytt diagram i editorn har det nya dokumentet alla lås på, så att filen aldrig ändras när du rullar, zoomar, byter flik, byter namnvisning eller väljer ett annat språk, skiftläge eller en annan typ av citattecken i kodgeneratorn i en editor. Inget verktyg slår på eller av ett enskilt lås: det gör du på fliken Inställningar i editorn. erd_import_json i läget replace ersätter dem alla med låsen i dokumentet som det läser in – se Import.
• Befintliga .erd-, .vuerd- och .vuerd.json-filer går också att öppna. En sökväg med någon annan filändelse nekas med invalidPath.
• I Windows nekas med invalidPath en sökväg som innehåller ett namn som Windows inte lagrar så som det är skrivet, innan dokumentet läses eller skrivs, även för läsningar: ett namn med kolon eller ett annat tecken som Windows inte godtar, som orders:v2.erd; ett enhetsnamn som NUL.erd eller CON.erd, oavsett skiftläge; eller ett namn som slutar med punkt eller blanksteg. Byt namn på filen, till exempel med - i stället för :.
• En fil som inte är ett dokument som editorn kan läsa, till exempel en som har kvar markörer från en sammanslagningskonflikt, nekas med invalidDocument och lämnas som den är. Den läses aldrig in som ett tomt diagram och skrivs tillbaka.

Agenten ändrar ett dokument bara via verktygen och instrueras att aldrig skriva filen själv.

erd_list_documents listar dokumenten med path, open, active, dirty och readonly. Verktyget frågar editorn som betjänar arbetskatalogen, vald på samma sätt som för ett dokument, och listar diagrammen som är öppna i den och sedan de ERD-filer som den betjänar: de i arbetsområdesmapparna i ett VS Code-fönster, i ett Obsidian-valv eller i varje projekt som är öppet i en JetBrains-IDE. Annars listar det ERD-filerna under arbetskatalogen, där en skrivskyddad fil märks med readonly och, i Windows, ett namn som Windows inte lagrar så som det är skrivet utelämnas.