Rozwiązywanie problemów z integracją Git w rozwoju magazynowym

Dotyczy: ✅ Magazynu w platformie Microsoft Fabric

Ten artykuł zawiera tematy dotyczące rozwiązywania problemów związanych z tworzeniem i wdrażaniem Fabric Data Warehouse z wbudowaną integracją z Gitem w Fabric.

Important

Ta funkcja jest dostępna w wersji zapoznawczej.

Odniesienia do obiektów magazynu z użyciem trzyczęściowej nazwy

Obiekt może odnosić się do innego obiektu w tym samym magazynie, używając trzyczęściowej nazwy, [warehouse_name].[schema_name].[object_name].

Trzyczęściowe nazewnictwo ma na celu odniesienie do innego magazynu. Gdy część bazy danych nazywa aktualny magazyn, build traktuje referencję jako zewnętrzną, a obiekt jest definiowany dwukrotnie w modelu.

Usuń część bazy danych z odniesień do obiektów magazynu:

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

Zmieniać się tylko odniesienia do obiektów magazynu. Autentyczne odwołania międzybazowe do innych magazynów, takie jak [Other_Warehouse].[Sales].[Orders], są wspierane i powinny pozostać as-is.

Important

Używaj trzyczęściowego nazewnictwa (database.schema.object) tylko dla referencji do endpointów analityki międzymagazynowej lub SQL, a nie do odwoływania się do obiektów w tym samym magazynie. Samoodwoływanie się do obiektów w tym samym magazynie za pomocą trójczęściowego nazewnictwa nie jest standardową praktyką modelowania i może powodować niezamierzone zewnętrzne odniesienia.

Tam, gdzie to możliwe, modeluj obiekty, używając nazewnictwa dwuczęściowego (schema.object) zamiast trzyczęściowego, nawet dla odniesień do siebie w obrębie tego samego magazynu. Ta konwencja poprawia spójność między narzędziami klienta i eliminuje niejednoznaczność wprowadzaną przez trzyczęściowe odniesienia.

Nieaktualny .sqlproj w repozytorium Git

Repozytorium Git może zawierać .sqlproj plik odwołujący się do starszej Microsoft.Build.Sql wersji SDK. Starsze SDK nie rozpoznaje nowszych składni Fabric Data Warehouse, takich jak IDENTITY kolumny i CLUSTER BY.

Problem ten dotyczy repozytoriów, których zawartość została zatwierdzona przed przeniesieniem magazynu na obecny format definicji. Najczęstsze sytuacje skutkujące nieaktualnym plikiem .sqlproj to:

  • Podłączanie nowego workspace do istniejącego repozytorium. Magazyn powstaje z tego, co tam zostało zrobione.
  • Rozgałęzienie się do nowego miejsca pracy.
  • Przywracam usunięty magazyn z Gita.
  • Synchronizacja z Gita zaraz po przejściu magazynu do obecnego formatu definicji, zanim jakakolwiek synchronizacja w przeciwnym kierunku się przeprowadziła.

Magazyny, które nie zostały przeniesione do obecnego formatu definicji, nie są objęte tym problemem, ponieważ starszy plik projektu nie jest używany do budowy.

Jak potwierdzić wersję .sqlproj SDK

Otwórz plik magazynu .sqlproj w repozytorium i sprawdź wersję SDK w XML:

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

Wersji, która jest za obecnym Microsoftem. Wersja pakietu Build.SQL oznacza przestarzały plik projektu. Na przykład, jeśli twoja wersja zaczyna się od 0.1.. Więcej informacji można znaleźć w Microsoft. Build.SQL i Templates Releases.

Aktualizacja wersji .sqlproj SDK Opcja A: najpierw synchronizacja warehouse do Gita

Jeśli magazyn już istnieje w workspace i jest zdrowy, commituj z workspace do Git przed synchronizacją w przeciwnym kierunku. Ta akcja regeneruje plik projektu z aktualną wersją SDK, po czym synchronizacja z Gitem działa normalnie.

Ta opcja jest preferowana tam, gdzie jest dostępna, ponieważ aktualizuje całą definicję, a nie tylko atrybut SDK.

Magazyn musi już być w aktualnym formacie definicji, aby ta opcja działała. Jeśli nie, najpierw zaktualizuj go w panelu Fabric Git, a potem zadeklaruj się w Git. Zatwierdzanie z magazynu, który nadal jest na starszym formacie definicji, zapisuje starszy format z powrotem do repozytorium i nie odświeża wersji SDK, więc następna synchronizacja kończy się w ten sam sposób. Jeśli nie możesz ulepszyć, użyj opcji napraw B .

Zaktualizuj wersję .sqlproj SDK opcja B: zaktualizuj plik .sqlproj bezpośrednio w Gicie

Użyj tej opcji, gdy magazyn jeszcze nie istnieje w docelowym workspace, na przykład gdy łączysz nowy workspace z istniejącym repozytorium, rozszerzasz się lub przywracasz usunięty magazyn. W takich przypadkach nie ma magazynu do synchronizacji, więc opcja naprawienia A nie jest dostępna.

Edytuj .sqlproj plik w repozytorium, aby używać najnowszej wersji Microsoft. Zbuduj wersję pakietu Build Sql i zatwierdz zmianę. Przykład:

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

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

Samo uruchomienie eksportu lub diff nie aktualizuje pliku projektu. Plik jest przepisywany tylko po zakończeniu commitu z workspace do Gita lub gdy edytujesz go ręcznie.

Kolumny niezakwalifikowane w obiektach odnoszących się do dwóch lub więcej tabel w innym magazynie

Zawsze podawaj i używaj aliasów tabel podczas odwoływania się do kolumn w zapytaniach T-SQL.

  • Gdy zapytanie T-SQL odnosi się do dwóch lub więcej tabel w innym magazynie, build nie może zweryfikować kolumny zapisanej bez aliasu tabeli do konkretnej tabeli. Tabele nie muszą mieć tej samej nazwy kolumny, aby ta niejednoznaczność istniała. Ta niejednoznaczność występuje w buildzie walidacyjnym.
  • Ta niejednoznaczność dotyczy zapytań T-SQL wewnątrz obiektów, które odwołują się do dwóch lub więcej tabel w innym magazynie w ramach tego samego ciała instrukcji.
  • Ta niejednoznaczność nie dotyczy zapytań T-SQL wewnątrz obiektów, które odwołują się tylko do jednej tabeli w innym magazynie, ponieważ przy jednym źródle nie ma co pozostawiać niejednoznaczności.
  • Ta niejednoznaczność nie dotyczy zapytań T-SQL, które pozostają całkowicie w jednym magazynie.

W poniższym przykładzie ma fieldinfotylko finame , więc SQL jest poprawny i działa poprawnie względem magazynu, ale w budowie walidacyjnej występuje niejasność.

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

Dodaj alias tabeli do każdej kolumny w dotkniętym obiekcie:

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

Niespójne wielkie litery w nazwach schematów

Twój magazyn może używać sortowania bez rozróżniania wielkości liter, więc sales i mają Sales ten sam schemat, ale twoje skrypty mogą zapisywać je w obu wersjach w różnych miejscach. Bazy danych bez rozróżniania wielkości liter zawsze to akceptowały, więc niespójność jest zwykle długotrwała i nieszkodliwa.

Gdy twoje skrypty odwołują się do dwóch lub więcej różnych obiektów w tym samym schemacie innego magazynu i zapisują ten schemat inaczej w każdym odwołaniu, build generuje CREATE SCHEMA instrukcje dla każdej pisowni. Ten problem dotyczy tylko magazynów, które odwołują się do innego magazynu i stosują sortację bez znaczenia wielkości liter.

  • Domyślnie magazyny w Fabric używają Latin1_General_100_BIN2_UTF8, sortowania na wielka litera. Magazyny wrażliwe na wielka a skalna nie są objęte tym wpływem. W tych magazynach sales są Sales dwie różne schematy, niezależnie od tego, czy tego chcesz, czy nie.
  • Baza danych nierozróżniająca wielkości wielkiej nie może zawierać zarówno , sales jak i Sales. Duplikat pochodzi tylko z różnic w pisowni w tekście SQL.

Sprawdź zestawienie magazynu i to, co ModelCollation jest określone w pliku .sqlproj . Szukaj ( CI nierozróżniające wielkość liter) lub CS (wrażliwe na wielkość liter).

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

Napraw.

Aby zidentyfikować niespójną wielką literę nazw schematów w definicjach obiektów magazynowych, porównaj wielkość liter schematu wymienionego w błędzie we wszystkich swoich skryptach. Szukaj dwóch cross-warehouse odniesień do tego samego schematu, które różnią się tylko przypadkiem.

Używaj jednej spójnej litery wszędzie, odpowiadającej rzeczywistej nazwie schematu w podanym magazynie. Na przykład używaj tylko Sales lub tylko 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];

Problem ten pojawia się, gdy mamy dwa różne obiekty z dwoma różnymi skalami schematu. Dwa odniesienia do tego samego obiektu z różnymi literami są poprawnie złożone i nie zawodzą.

Sortowanie kolumn

Jeśli klauzula COLLATE kolumny wyraźnie określa tę samą kolację co domyślna kolacja magazynu, ekstrakcja schematu Fabric (oparta na DacFx) traktuje jawną sortację jako równoważną z jej nieokreślaniem w ogóle. W tym przypadku:

  • Klauzula jawna COLLATE nie pojawia się w definicji przedmiotu wyodrębnionej do repozytorium Gita.
  • Kolumna nie pojawia się jako różnica w Git Changes, Updates czy porównaniach pipeline'ów wdrożeniowych, ponieważ nie ma efektywnej różnicy względem domyślnej sortacji magazynu.

Tylko kolumny, których sortowanie różni się od domyślnego zestawienia magazynu, zachowują COLLATE wyraźną klauzulę w kontroli wersji źródłowych, a różnice pojawiają się tylko w zmianach w sortowaniu tych kolumn.

Na przykład rozważmy magazyn, którego kolacja to 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 nie ma jawnej kolacji i dziedziczy domyślną sortację magazynu.
  • LastNameBin ma wyraźną sortację różniącą się od domyślnej sortacji magazynu, więc jest zachowywana w wyodrębnionej definicji i zawsze pojawia się w porównaniach, jeśli się zmieni.
  • Email ma wyraźną sortację odpowiadającą domyślnej sortacji magazynu. Mimo że klauzula COLLATE ta jest obecna w T-SQL, nie pojawia się w definicji wyodrębnionej przez Git ani w porównaniach potoków Git czy wsparcia, ponieważ jest równoważna domyślnej.

Niejednoznaczne błędy kolumn z duplikatami obiektów kandydatów

Zatwierdzenie lub aktualizacja z Gita może zakończyć się niepowodzeniem z niejednoznacznym błędem kolumnowym, którego lista kandydatów zawiera separator, :: na przykład:

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

Separator :: odróżnia ten błąd od rzeczywistej niejednoznaczności opisanej w kolumnach Unqualified w obiektach odwołujących się do dwóch lub więcej tabel w innym magazynie. Dodanie aliasu tabelowego nie rozwiązuje problemu, ponieważ alias pojawia się na liście kandydatów i błąd nadal występuje.

  1. Po pierwsze, wyklucz te dwie częstsze przyczyny:

    • Naprawdę brakujący lub źle nazwany przedmiot. Jeśli ten sam commit lub aktualizacja zgłasza również nierozwiązane odwołanie do konkretnego brakującego obiektu, na przykład , SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable]najpierw napraw to odwołanie. Kandydaci :: zazwyczaj przechodzą razem z nim.
    • To naprawdę niejednoznaczna kolumna. Jeśli kolumna niezakwalifikowana zostanie wybrana na połączeniu dwóch źródeł, które oba ujawniają kolumnę o tej nazwie, kwalifikuj kolumnę jej aliasem tabelowym, na przykład a.[NCESID]. SQL Server również odrzuciłby to zapytanie, więc nie dotyczy ono integracji z Gitem.

  2. Jeśli istnieje każdy obiekt z referencji i żadna kolumna nie jest naprawdę niejednoznaczna, kandydaci :: są znanym problemem w walidacji uruchamianej podczas commitów i aktualizacji z Gita, śledzonej przez zespół produktowy. Spróbuj następujących obejść, w kolejności:

    1. Zastąpienie SELECT * wewnętrznych CTE i tabel pochodnych jawną listą kolumn.
    2. Podziel widok tak, aby każde niejednoznaczne źródło było zdefiniowane w osobnym widoku i odwołuj się do tego widoku zamiast powtarzać podstawowe zapytanie.
    3. Unikaj łączenia OPENROWSET(BULK ...) się z innym dynamicznie ukształtowanym źródłem w tym samym zdaniu.

Jeśli żadne z tych rozwiązań nie rozwiąże błędu, pobierz definicję obiektu nazwanego w błędzie i otwórz żądanie wsparcia. Ograniczenia specyficzne dla pipeline'ów wdrożeniowych znajdziesz w sekcji Ograniczenia.

Treści powiązane

  • Last updated on