Řešení problémů s integrací Git pro vývoj ve skladu

Platí pro: ✅ Warehouse v Microsoft Fabric

Tento článek obsahuje témata pro řešení problémů s vývojem a nasazením Fabric Data Warehouse s integrovanou integrací Git Fabric.

Important

Tato funkce je ve verzi Preview.

Odkazy na objekty skladu pomocí třídílného názvu

Objekt může odkazovat na jiný objekt ve stejném skladu pomocí třídílného názvu, [warehouse_name].[schema_name].[object_name].

Třídílné pojmenování je určeno pro odkazování na jiný sklad. Když databázová část pojmenuje aktuální sklad, build považuje referenci za externí a objekt je v modelu definován dvakrát.

Odstraňte databázovou část z odkazů na objekty skladu:

-- 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;

Stačí změnit pouze odkazy na objekty skladu. Podporovány jsou skutečné křížové databázové odkazy na jiné sklady, jako [Other_Warehouse].[Sales].[Orders]je , a měly by zůstat as-is.

Important

Používejte třífázové pojmenování (database.schema.object) pouze pro odkazy na endpointy mezi sklady nebo SQL analytikou, nikoli pro odkazování na objekty ve stejném skladu. Samoodkazování objektů ve stejném skladu pomocí třífázového pojmenování není standardní modelovací praxe a může vytvářet nechtěné externí reference.

Kde je to možné, modelujte objekty pomocí dvoudílného pojmenování (schema.object) místo třídílného, i pro sebereferenci ve stejném skladu. Tato konvence zlepšuje konzistenci napříč klientskými nástroji a zabraňuje nejednoznačnosti způsobené tříčlennými odkazy.

Zastaralý .sqlproj v Git repozitáři

Git repozitář může obsahovat soubor, .sqlproj který odkazuje na starší Microsoft.Build.Sql verzi SDK. Starší SDK nerozpoznává novější Fabric Data Warehouse syntaxi, jako IDENTITY jsou sloupce a CLUSTER BY.

Tento problém se týká repozitářů, jejichž obsah byl commitován před přesunem skladu na současný formát definice. Nejčastější situace, kdy vznikne zastaralý .sqlproj soubor, jsou:

  • Připojení nového pracovního prostoru k existujícímu repozitáři. Sklad se vytváří z toho, co tam bylo uloženo.
  • Rozšiřování do nového pracovního prostoru.
  • Obnova smazaného skladu z Gitu.
  • Synchronizace z Gitu hned poté, co sklad přešel na současný formát definice, ještě před tím, než jakákoli synchronizace v opačném směru proběhne.

Sklady, které nejsou přesunuty do současného formátu definice, nejsou ovlivněny, protože starší projektový soubor se nepoužívá pro stavbu.

Jak potvrdit verzi .sqlproj SDK

Otevřete soubor skladu .sqlproj v repozitáři a zkontrolujte verzi SDK v XML:

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

Verzi, která zaostává za současným Microsoftem. Verze balíčku Build.SQL označuje zastaralý projektový soubor. Například pokud vaše verze začíná na 0.1.. Pro více informací viz Microsoft. Build.SQL a vydání šablon.

Aktualizace verze .sqlproj SDK možnost A: nejdřív synchronizovat warehouse s Gitem

Pokud sklad už v pracovním prostoru existuje a je zdravý, pověřte ho z pracovního prostoru do Gitu před synchronizací opačným směrem. Tato akce znovu generuje projektový soubor s aktuální verzí SDK, po čemž synchronizace z Gitu funguje normálně.

Tato možnost je preferována tam, kde je k dispozici, protože aktuálně zobrazuje celou definici, nikoli pouze atribut SDK.

Sklad musí být již na aktuálním formátu definice, aby tato možnost fungovala. Pokud ne, nejdřív ho upgradujte v panelu Fabric Git a pak se zavázejte do Gitu. Commitování ze skladu, který je stále na starším formátu definice, zapíše starší formát zpět do repozitáře a neobnoví verzi SDK, takže další synchronizace selže stejným způsobem. Pokud nemůžete upgradovat, použijte místo toho možnost opravy B .

Aktualizace verze .sqlproj SDK možnost B: aktualizovat soubor .sqlproj přímo v Gitu

Použijte tuto možnost, když sklad v cílovém pracovním prostoru ještě neexistuje, například když připojujete nový pracovní prostor k existujícímu repozitáři, rozšiřujete se nebo obnovujete smazaný sklad. V těchto případech není sklad, ze kterého by se dalo synchronizovat, takže možnost opravy A není dostupná.

Upravte .sqlproj soubor v repozitáři tak, aby používal nejnovější Microsoft. Build.SQL balíček a commit změnu. Příklady:

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

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

Samotné spuštění exportu nebo diff souboru neaktualizuje soubor. Soubor se přepíše pouze tehdy, když je commit z pracovního prostoru do Gitu dokončen, nebo když ho upravíte ručně.

Neomezené sloupce v objektech, které odkazují na dvě nebo více tabulek v jiném skladu

Při odkazování na sloupce v T-SQL dotazech vždy poskytujte a používejte aliasy tabulek.

  • Když dotaz T-SQL odkazuje na dvě nebo více tabulek v jiném skladu, sestava nemůže ověřit sloupec napsaný bez aliasu tabulky pro konkrétní tabulku. Tabulky nemusí mít společný název sloupce, aby tato nejasnost existovala. Tato nejasnost existuje i v validační sestavě.
  • Tato nejednoznačnost ovlivňuje T-SQL dotazy uvnitř objektů, které odkazují na dvě nebo více tabulek v jiném skladu ve stejném těle příkazu.
  • Tato nejednoznačnost neovlivňuje T-SQL dotazy uvnitř objektů, které odkazují pouze na jednu tabulku v jiném skladu, protože u jednoho zdroje není mezi čím nejasností.
  • Tato nejasnost se netýká dotazů do T-SQL, které zůstávají zcela v jednom skladu.

V následujícím příkladu má fieldinfopouze finame , takže SQL je platné a správně běží proti skladu, ale ve validační sestavení existuje nejasnost.

-- 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];

Přidejte alias tabulky ke každé referenci sloupců v dotčeném objektu:

-- 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];

Nekonzistentní velká písmena názvů schémat

Váš sklad může použít sortaci bez rozlišování na velikost písmen, takže sales a jsou Sales stejné schéma, ale vaše skripty to mohou psát oběma způsoby na různých místech. Databáze bez ohledu na velikost písmen to vždy akceptovaly, takže tato nekonzistence je obvykle dlouhodobá a neškodná.

Když vaše skripty odkazují na dva nebo více různých objektů ve stejném schématu jiného skladu a v každé referenci toto schéma hláskují jinak, build vygeneruje pro každý pravopis příkaz.CREATE SCHEMA Tento problém se týká pouze skladů, které odkazují na jiný sklad a používají sortaci bez rozlišení velikosti (case-in).

  • Ve výchozím nastavení sklady ve Fabric používají Latin1_General_100_BIN2_UTF8, velikostně a pádově rozlišující kolaci. Sklady citlivé na velikost a písmena nejsou ovlivněny. V těchto skladech salesSales jsou dvě odlišná schémata, ať už to zamýšlíte nebo ne.
  • Databáze bez rozlišení velikosti nemůže obsahovat ani , sales ani Sales. Duplikát vzniká pouze z rozdílného pravopisu ve vašem SQL textu.

Zkontrolujte skladové uspořádání a požadavky ModelCollation uvedené ve spisu .sqlproj . Hledejte ( CI necitlivé na velká písmena) nebo CS (citlivé na velká písmena).

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

Opravit

Pro identifikaci nekonzistentního velkého písmena názvů schématu ve vašich definicích objektů skladu porovnejte velká písmena schématu uvedeného v chybě napříč všemi skripty. Hledejte dva odkazy na stejné schéma mezi sklady, které se liší pouze případem.

Používejte jednotné velké písmeno všude, odpovídající skutečnému názvu schématu v odkazovaném skladu. Například použijme pouze nebo Sales pouze 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];

S tímto problémem narazíte, když máte dva různé objekty se dvěma různými velkými písmeny schématu. Dva odkazy na stejný objekt s různou velikostí jsou správně složeny a neselžou.

Kolace sloupců

Pokud klauzule COLLATE sloupce výslovně specifikuje stejnou kolaci jako výchozí kolace skladu, extrakce schématu Fabric (založená na DacFx) považuje explicitní kolaci za ekvivalentní tomu, že ji vůbec nespecifikuje. V tomto případě:

  • Explicitní COLLATE klauzule se neobjevuje v definici položky extrahované do Git repozitáře.
  • Sloupec se nezobrazuje jako rozdíl v Git Changes, Updates nebo porovnání pipeline nasazení, protože není žádný efektivní rozdíl oproti výchozímu třídění skladu.

Pouze sloupce, jejichž třídění se liší od výchozího kolování skladu, si ponechávají explicitní COLLATE klauzuli ve source managementu a pouze změny v sortaci těchto sloupců se objevují jako rozdíly.

Například uvažujme sklad, jehož kolace je 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 nemá explicitní třídění a dědí výchozí třídění skladu.
  • LastNameBin má explicitní kolaci, která se liší od výchozí kolace skladu, takže je zachována v extrahované definici a vždy se objeví při porovnáních, pokud se změní.
  • Email má explicitní třídění, které odpovídá výchozímu kolování skladu. I když je klauzule COLLATE přítomna v T-SQL, neobjevuje se v definici extrahované v Git ani v porovnání Git či deployment pipeline, protože je ekvivalentní výchozímu stavu.

Nejasné chyby sloupců s duplicitními kandidátskými objekty

Commitování nebo aktualizace z Gitu může selhat s nejasnou chybou sloupce, jejíž kandidátní seznam obsahuje oddělovač, :: například:

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].

Oddělovač :: odlišuje tuto chybu od skutečné nejednoznačnosti popsané ve sloupcích Unqualified u objektů, které odkazují na dvě nebo více tabulek v jiném skladu. Přidání tabulového aliasu problém nevyřeší, protože alias se objevuje v seznamu kandidátů a chyba stále přetrvává.

  1. Nejprve vylučte tyto dvě častější příčiny:

    • Opravdu chybějící nebo špatně pojmenovaný předmět. Pokud stejný commit nebo aktualizace také hlásí nevyřešenou referenci na konkrétní chybějící objekt, například SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable], opravte tuto referenci jako první. Kandidáti :: obvykle souhlasí s ním.
    • Opravdu nejednoznačný sloupek. Pokud je nekvalifikovaný sloupec vybrán přes spojení dvou zdrojů, které oba odhalují sloupec s tímto jménem, kvalifikujte sloupec jeho aliasem tabulky, například a.[NCESID]. SQL Server by tento dotaz také odmítl, takže to není specifické pro integraci s Gitem.

  2. Pokud existují všechny odkazované objekty a žádný sloupec není skutečně nejednoznačný, kandidáti :: jsou známým problémem ve validaci, která probíhá během commitů a aktualizací z Gitu, sledováno produktovým týmem. Vyzkoušejte tyto obcházky v pořadí:

    1. Nahraďte SELECT * uvnitř CTE a odvozené tabulky explicitním seznamem sloupců.
    2. Rozdělte pohled tak, aby každý nejednoznačný zdroj byl definován ve svém vlastním pohledu, a odkazujte na tento pohled místo opakování základního dotazu.
    3. Vyhněte se spojování OPENROWSET(BULK ...) s jiným dynamicky tvarovaným zdrojem ve stejném tvrzení.

Pokud žádná z těchto možností chybu nevyřeší, shromáždíte definici objektu pojmenovaného v chybě a otevřete požadavek na podporu. Pro omezení specifická pro nasazení pipeline viz Omezení.

Související obsah

  • Last updated on