Probleemoplossing voor Git-integratie voor warehouse-ontwikkeling

Van toepassing op: ✅ Warehouse in Microsoft Fabric

Dit artikel bevat problemen met problemen voor het ontwikkelen en uitrollen van Fabric Data Warehouse met de ingebouwde Git-integratie van Fabric.

Important

Deze functie is beschikbaar als preview-versie.

Verwijzingen naar de eigen objecten van het magazijn door gebruik te maken van een naam in drie delen

Een object kan een ander object in hetzelfde warehouse refereren door een driedelige naam te gebruiken, [warehouse_name].[schema_name].[object_name].

Driedelige naamgeving is bedoeld om naar een ander magazijn te verwijzen. Wanneer het databasedeel het huidige warehouse benoemt, behandelt de build de referentie als extern, en wordt het object uiteindelijk twee keer gedefinieerd in het model.

Verwijder het databasegedeelte uit verwijzingen naar de eigen objecten van het warehouse:

-- Fails: the warehouse is named MyWarehouse and references itself by name
CREATE VIEW [Sales].[CustomerSummary] AS
SELECT c.[CustomerId], c.[OrderDate]
FROM [MyWarehouse].[Sales].[Customers] AS c;

-- Works
CREATE VIEW [Sales].[CustomerSummary] AS
SELECT c.[CustomerId], c.[OrderDate]
FROM [Sales].[Customers] AS c;

Alleen verwijzingen naar de eigen objecten van het magazijn hoeven te veranderen. Echte cross-database referenties naar andere warehouses, zoals [Other_Warehouse].[Sales].[Orders], worden ondersteund en moeten as-isblijven.

Important

Gebruik alleen drieledige naamgeving (database.schema.object) voor cross-warehouse of cross-SQL analytics endpointreferenties, niet om objecten binnen hetzelfde warehouse te refereren. Zelfreferentie van objecten in hetzelfde warehouse met driedelige naamgeving is geen standaard modelleringspraktijk en kan onbedoelde externe referenties veroorzaken.

Waar mogelijk, modelleer objecten door tweedelige naamgeving (schema.object) te gebruiken in plaats van driedelige naamgeving, zelfs voor zelfreferenties binnen hetzelfde magazijn. Deze conventie verbetert de consistentie tussen clienttools en voorkomt de ambiguïteit die wordt geïntroduceerd door driedelige referenties.

Verouderde .sqlproj in de Git-repository

De Git-repository kan een .sqlproj bestand bevatten dat verwijst naar een oudere Microsoft.Build.Sql SDK-versie. De oudere SDK herkent nieuwere Fabric Data Warehouse syntaxis zoals IDENTITY columns en CLUSTER BY.

Dit probleem betreft repositories waarvan de inhoud werd vastgelegd voordat het warehouse overstapte naar het huidige definitieformaat. De meest voorkomende situaties die resulteren in een verouderd .sqlproj-bestand zijn:

  • Een nieuwe werkruimte koppelen aan een bestaande repository. Het magazijn wordt gemaakt van wat daar wordt toegewezen.
  • Uitbreiden naar een nieuwe werkplek.
  • Een verwijderd warehouse herstellen vanuit Git.
  • Synchronisatie van Git direct nadat het warehouse is overgestapt naar het huidige definitieformaat, voordat er enige synchronisatie in de andere richting is uitgevoerd.

Magazijnen die niet naar het huidige definitieformaat zijn verplaatst, worden niet beïnvloed, omdat het oudere projectbestand niet wordt gebruikt om te bouwen.

Hoe verifieer je .sqlproj SDK-versie

Open het .sqlproj bestand van het magazijn in de repository en controleer de SDK-versie in de XML:

<Sdk Name="Microsoft.Build.Sql" Version="2.2.0" />

Een versie die achterloopt op het huidige Microsoft. De Build.Sql-pakketversie geeft een verouderd projectbestand aan. Bijvoorbeeld, als jouw versie begint met 0.1.. Voor meer informatie, zie Microsoft. Build.Sql en templates releases.

Update .sqlproj SDK versie optie A: sync warehouse eerst met Git

Als het warehouse al in de werkruimte bestaat en gezond is, commit dan van de werkruimte naar Git voordat je in de andere richting synchroniseert. Deze actie genereert het projectbestand opnieuw met de huidige SDK-versie, waarna synchronisatie vanuit Git normaal werkt.

Deze optie heeft de voorkeur waar beschikbaar, omdat het de volledige definitie up-to-date brengt in plaats van alleen het SDK-attribuut.

Het magazijn moet al op het huidige definitieformaat staan om deze optie te laten werken. Als dat niet zo is, upgrade het dan eerst in het Fabric Git-paneel en commit dan naar Git. Committen vanuit een warehouse dat nog steeds op het oudere definitieformaat zit, schrijft het oudere formaat terug naar de repository en ververst de SDK-versie niet, dus de volgende synchronisatie faalt op dezelfde manier. Als je niet kunt upgraden, gebruik dan optie B voor het repareren .

Update .sqlproj SDK versie optie B: werk het .sqlproj-bestand direct bij in Git

Gebruik deze optie wanneer het warehouse nog niet bestaat in de doelwerkruimte, bijvoorbeeld wanneer je een nieuwe werkruimte verbindt met een bestaande repository, uitbreidt of een verwijderd warehouse herstelt. In die gevallen is er geen magazijn om mee te synchroniseren, dus is optie A niet beschikbaar.

Bewerk het .sqlproj bestand in de repository om de nieuwste Microsoft te gebruiken. Build.SQL package versie en commit de wijziging. Voorbeeld:

<!-- Before -->
<Sdk Name="Microsoft.Build.Sql" Version="0.1.19-preview" />

<!-- After -->
<Sdk Name="Microsoft.Build.Sql" Version="2.2.0" />

Een export of een differentieel op zichzelf draaien werkt het projectbestand niet bij. Het bestand wordt alleen herschreven wanneer een commit van de workspace naar Git voltooid is, of wanneer je het handmatig bewerkt.

Ongekwalificeerde kolommen in objecten die verwijzen naar twee of meer tabellen in een ander magazijn

Geef en gebruik altijd tabelaliasen bij het refereren naar kolommen in T-SQL-queries.

  • Wanneer een T-SQL-query twee of meer tabellen in een ander warehouse verwijst, kan de build een kolom die zonder tabelalias is geschreven niet valideren voor een specifieke tabel. De tabellen hoeven geen kolomnaam te delen om deze ambiguïteit te laten bestaan. Deze ambiguïteit bestaat in de validatie-build.
  • Deze ambiguïteit beïnvloedt T-SQL-queries binnen objecten die twee of meer tabellen in een ander warehouse binnen dezelfde statementbody verwijzen.
  • Deze ambiguïteit heeft geen invloed op T-SQL-queries binnen objecten die slechts één tabel in een ander warehouse verwijzen, omdat er bij één bron niets is om ambigu tussen te zijn.
  • Deze ambiguïteit heeft geen invloed op T-SQL-queries die volledig binnen één warehouse blijven.

In het volgende voorbeeld heeft fieldinfoalleen finame , dus de SQL is geldig en draait correct tegen het warehouse, maar er bestaat ambiguïteit in de validatiebuild.

-- Fails: two tables from another warehouse, and 'finame' isn't alias-qualified
CREATE PROCEDURE [dbo].[LoadFieldInfo] AS
SELECT finame
FROM   [OtherWarehouse].[halo].[fieldinfo] AS f
INNER JOIN   [OtherWarehouse].[halo].[lookup]    AS l ON f.[id] = l.[id];

Voeg een tabelalias toe aan elke kolomreferentie in het getroffen object:

-- Works: every column carries its table alias
CREATE PROCEDURE [dbo].[LoadFieldInfo] AS
SELECT f.[finame]
FROM   [OtherWarehouse].[halo].[fieldinfo] AS f
INNER JOIN   [OtherWarehouse].[halo].[lookup]    AS l ON f.[id] = l.[id];

Inconsistente hoofdlettergebruik van schemanamen

Je magazijn kan een hoofdletter-ongevoelige collatie gebruiken, dus salesSales en zijn hetzelfde schema, maar je scripts kunnen het op verschillende plekken op beide manieren spellen. Databases met een naam-in-kas-gevoelige situatie hebben dat altijd geaccepteerd, dus de inconsistentie is meestal langdurig en onschadelijk.

Wanneer je scripts twee of meer verschillende objecten in hetzelfde schema van een ander warehouse verwijzen en dat schema in elke referentie anders spellen, genereert de build voor elke spelling een CREATE SCHEMA statement. Dit probleem treft alleen magazijnen die een ander magazijn verwijzen en een case-insensitive collatie gebruiken.

  • Standaard gebruiken Latin1_General_100_BIN2_UTF8magazijnen in Fabric , een hoofdlettergevoelige collatie. Case-gevoelige magazijnen worden niet beïnvloed. In die magazijnen sales zijn er Sales twee verschillende schema's, of je dat nu wilt of niet.
  • Een naam-in-hoofd gevoelige database kan niet zowel sales als Sales. De duplicaat komt alleen door de verschillende spellingen in je SQL-tekst.

Controleer de magazijn-collatie en de specificaties ModelCollation in het .sqlproj bestand. Zoek naar CI (hoofdlettergevoelig) of CS (hoofdlettergevoelig).

<ModelCollation>1033, CI</ModelCollation>   <!-- case-insensitive: affected -->
<ModelCollation>1033, CS</ModelCollation>   <!-- case-sensitive: not affected -->

Repareren

Om inconsistente schemanaam-hoofdlettergebruik in je warehouse-objectdefinities te identificeren, vergelijk je de hoofdlettergebruik van het schema dat in de fout is genoemd over al je scripts. Zoek naar twee cross-warehouse-verwijzingen naar hetzelfde schema die alleen in geval verschillen.

Gebruik overal één consistente hoofdletter, die overeenkomt met de daadwerkelijke schemanaam in het verwezen magazijn. Gebruik bijvoorbeeld alleen Sales of alleen sales.

-- Fails: two objects in the same schema, referenced with different capitalization
CREATE VIEW [dbo].[v_one] AS SELECT * FROM [OtherWarehouse].[sales].[Orders];
GO
CREATE VIEW [dbo].[v_two] AS SELECT * FROM [OtherWarehouse].[Sales].[Customers];

-- Works: same capitalization in both references
CREATE VIEW [dbo].[v_one] AS SELECT * FROM [OtherWarehouse].[Sales].[Orders];
GO
CREATE VIEW [dbo].[v_two] AS SELECT * FROM [OtherWarehouse].[Sales].[Customers];

Je ondervindt dit probleem als je twee verschillende objecten hebt met twee verschillende schema-hoofdletters. Twee verwijzingen naar hetzelfde object met verschillende hoofdletters worden correct gevouwen en falen niet.

Kolomcollatie

Als de COLLATE clausule van een kolom expliciet dezelfde collatie specificeert als de standaardcollatie van het magazijn, behandelt Fabric's schema-extractie (gebaseerd op DacFx) de expliciete collatie als gelijk aan het helemaal niet specificeren van een collatie. In dit geval:

  • De expliciete COLLATE clausule verschijnt niet in de itemdefinitie die is uitgepakt in de Git-repository.
  • De kolom verschijnt niet als verschil in Git-wijzigingen, updates of vergelijkingen van deployment-pipelines, omdat er geen effectief verschil is met de standaardcollatie van het warehouse.

Alleen kolommen waarvan de collatie afwijkt van de standaardcollatie van het magazijn, behouden een expliciete clausule COLLATE in de broncode, en alleen wijzigingen in die kolommen verschijnen als verschillen.

Neem bijvoorbeeld een magazijn waarvan de collatie is Latin1_General_100_CI_AS_KS_WS_SC_UTF8:

CREATE TABLE dbo.MixedCollationExample
(
    CustomerId      INT             NOT NULL,
    FirstName       VARCHAR(100)    NOT NULL,                                               -- inherits warehouse collation
    LastNameBin     VARCHAR(100)    COLLATE Latin1_General_100_BIN2_UTF8 NOT NULL,          -- column override, differs from warehouse collation
    Email           VARCHAR(256)    COLLATE Latin1_General_100_CI_AS_KS_WS_SC_UTF8 NULL     -- explicit collation, matches warehouse collation
);
  • FirstName heeft geen expliciete collatie en erft de standaardcollatie van het magazijn.
  • LastNameBin heeft een expliciete collatie die verschilt van de standaardcollatie van het magazijn, dus deze wordt behouden in de geëxtraheerde definitie en verschijnt altijd in vergelijkingen als deze verandert.
  • Email heeft een expliciete collatie die overeenkomt met de standaardcollatie van het magazijn. Hoewel de COLLATE clausule aanwezig is in de T-SQL, verschijnt hij niet in de door Git geëxtraheerde definitie of in Git- of deployment-pipelinevergelijkingen, omdat het gelijkwaardig is aan de standaard.

Dubbelzinnige kolomfouten met dubbele kandidaatobjecten

Committen of updaten vanuit Git kan mislukken met een ambigue kolomfout waarvan de kandidatenlijst een :: separator bevat, bijvoorbeeld:

SQL71501: View: [dbo].[SchoolSummary] contains an unresolved reference to an object.
Either the object does not exist or the reference is ambiguous because it could refer
to any of the following objects: [dbo].[SchoolSummary].[NCESID] or
[dbo].[SchoolSummary].[ss]::[NCESID].

De :: scheider onderscheidt deze fout van de echte ambiguïteit beschreven in Onbevoegde kolommen in objecten die verwijzen naar twee of meer tabellen in een ander magazijn. Het toevoegen van een tabelalias lost het niet op, want de alias verschijnt in de kandidatenlijst en de fout blijft bestaan.

  1. Sluit eerst deze twee meer voorkomende oorzaken uit:

    • Een echt ontbrekend of verkeerd benoemd object. Als dezelfde commit of update ook een onopgeloste verwijzing naar een specifiek ontbrekend object rapporteert, zoals SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable], fix die referentie eerst. De :: kandidaten maken meestal mee de weg mee.
    • Een oprecht dubbelzinnige column. Als een niet-gekwalificeerde kolom wordt geselecteerd boven een join van twee bronnen die beide een kolom met die naam blootleggen, kwalificeer dan de kolom met zijn tabelalias, bijvoorbeeld a.[NCESID]. SQL Server zou deze query ook weigeren, dus het is niet specifiek voor Git-integratie.

  2. Als elk gerefereerd object bestaat en geen enkele kolom echt ambigu is, zijn de :: kandidaten een bekend probleem in de validatie die draait tijdens commits en updates vanuit Git, gevolgd door het productteam. Probeer deze omwegen, in volgorde:

    1. Vervang SELECT * binnen CTE's en afgeleide tabellen door een expliciete kolomlijst.
    2. Splits de weergave zodat elke ambiguïte bron in zijn eigen weergave wordt gedefinieerd, en verwijs naar die weergave in plaats van de onderliggende query te herhalen.
    3. Vermijd het om in dezelfde uitspraak een andere dynamisch gevormde bron te joinen OPENROWSET(BULK ...) .

Als geen van deze de fout oplost, verzamel dan de definitie van het object dat in de fout wordt genoemd en open een supportverzoek. Voor beperkingen specifiek voor deployment-pijplijnen, zie Beperkingen.

Verwante onderwerpen

  • Last updated on