Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
När du arbetar med Git-anslutna arbetsytor i Microsoft Fabric kan det uppstå situationer där objekt på din arbetsyta och objekt i Git-grenen har samma namn och typ, men har olika logiska ID:er. Det här matchningsfelet kan utlösa en varning om metadataöverskrivning och kräver att du bestämmer vilket logiskt ID som ska behållas.
Den här artikeln förklarar vad logiska ID:er är, varför konflikter inträffar och hur du löser dem på ett säkert sätt.
Vad är ett logiskt ID?
När din Fabric-arbetsyta är ansluten till en Git-gren associeras varje objekt i arbetsytan med de logiska ID:n som definierats i den grenen. Dessa ID:er representerar "identiteten" för varje objekt i Microsoft Fabric-arbetsytor. Ett logiskt ID är en automatiskt genererad identifierare för flera arbetsytor som ansluter ett objekt i en arbetsyta med motsvarande objekt i en Git-gren. Objekt med samma logicalId antas vara desamma.
Mer information om logiska ID:er och hur Infrastruktur representerar objekt i källkontroll finns i dokumentationen för Git-integrerings källkodsformat.
Vad är en logisk ID-konflikt?
En logisk ID-konflikt uppstår när Fabric identifierar två objekt som har samma namn och objekttyp men olika logiska ID:n – ett i arbetsytan och ett i den Gitanslutna grenen. Eftersom logiska ID:n är de unika bindningsnycklarna mellan infrastrukturobjekt och deras Git-representationer innebär ett matchningsfel att Infrastrukturresurser inte vet vilken version som ska behandlas som objektets "sanna" identitet.
När en konflikt identifieras visas dialogrutan Bekräfta metadataöverskrivning som liknar följande:
Den här konflikten anger att ditt arbetsyteobjekt har ett annat logiskt ID än den version av objektet som kommer från källkontrollen.
Om åtgärden bekräftas kommer det logiska ID:t från källkontrollen att ersätta det matchade objektets logiska ID på arbetsytan.
Vanliga scenarier som leder till konflikter
Logiska ID-inkonsekvenser kan inträffa när du:
| Scenario | Beskrivning |
|---|---|
| Ansluta en arbetsyta till en icke-tom Git-mapp | Om Git-lagringsplatsen innehåller objekt som matchar arbetsyteobjekten efter namn och typ men har olika logiska ID:er, uppmanar Fabric dig att bekräfta att arbetsytans metadata skrivs över. |
| Växla till en annan gren | Om du ändrar bransch kan objektdefinitioner dyka upp som inte delar samma logiska ID som arbetsytans versioner. |
| Förgrena till en ny gren baserat på en annan gren än den anslutna grenen | Introducerar en andra, oberoende sort av objekt-ID:n i en arbetsyta som redan är mappad till en specifik Git-gren. |
| Förgrena till en befintlig arbetsyta som innehåller objekt | När du förgrenar från en arbetsyta till en befintlig arbetsyta som redan innehåller objekt, justerar Microsoft Fabric målarbetsytans metadata med den nya anslutna grenen som skapades från källarbetsytans grenmetadata. |
Lösa logiska ID-konflikter
När en konflikt inträffar måste du bestämma om du vill skriva över arbetsytans metadata eller behålla dem.
Alternativ 1: Skriv över metadata för arbetsytan (ta Git-version)
Om du bekräftar överskrivningen:
- Det logiska ID:t från källkontrollen ersätter det befintliga logiska ID:t på arbetsytan.
- Metadata för arbetsytan matchar nu Git-versionen.
Använd det här alternativet när du vill att arbetsytan ska vara helt i linje med git-grenen.
Påverkan på befintliga automatiseringar
Genom att välja att skriva över arbetsytans metadata ersätter du de befintliga logiska ID:erna på arbetsytan med de versioner som kommer från Git. Detta kan bryta alla befintliga automatiseringar som förlitar sig på de aktuella logiska ID:erna för att identifiera objekt konsekvent. Eftersom dessa automatiseringar refererar till specifika objektidentiteter gör ändring av dessa logiska ID:n effektivt arbetsyteobjekten "nya" ur arbetsflödenas perspektiv. Därför kan underordnade jobb misslyckas med att hitta objekt, hoppa över uppdateringar eller generera dubbletter tills automationslogik har uppdaterats för att identifiera de nya identiteterna.
Alternativ 2: Behåll befintliga arbetsytemetadata (behåll arbetsyteversionen)
Om du vill bevara arbetsytans logiska ID:
- Bekräfta inte överskrivningen.
- Uppdatera Git-förvaret med de logiska ID:n som för närvarande finns på arbetsytan.
Du kan göra detta genom att:
- Checka ut eller checka in till en annan gren och hämta arbetsytans metadata till Git, eller
- Byta namn på objekten i Git, vilket gör att Fabric behandlar dem som tilläggs-/borttagningsåtgärder i stället för motstridiga uppdateringar.