Fabric depo geliştirme için Git entegrasyonunu sorun çözme

Şunlar için geçerlidir: ✅ Microsoft Fabric'te Ambar

Bu makale, Fabric'nin yerleşik Git entegrasyonuyla Fabric Data Warehouse geliştirme ve dağıtım konularını içermektedir.

Important

Bu özellik önizleme aşamasındadır.

Deponun kendi nesnelerine üç bölümlü isimle yapılan referanslar

Bir nesne, aynı depodaki başka bir nesneye üç parçalı bir isim kullanarak referans verebilir, [warehouse_name].[schema_name].[object_name].

Üç bölümlü adlandırma, farklı bir depoya atıfta bulunmak için tasarlanmıştır. Veritabanı parçası mevcut depoyu adlandırdığında, derleme referansı dışsal olarak ele alır ve nesne modelde iki kez tanımlanır.

Veritabanı parçasını deponun kendi nesnelerine yapılan referanslardan kaldırın:

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

Sadece deponun kendi nesnelerine yapılan referanslar değişmeli. Diğer depolara yönelik gerçek çapraz veritabanı referansları, [Other_Warehouse].[Sales].[Orders]örneğin , desteklenir ve as-iskalmalıdır.

Important

Üç bölümlü adlandırma (database.schema.object) yalnızca çapraz depo veya çapraz SQL analitik uç nokta referansları için kullanın, aynı depo içindeki nesnelere referans vermek için değil. Aynı depoda nesnelere üç bölümlü adlandırma kullanarak kendine referans vermek standart bir modelleme uygulaması değildir ve farkında olmadan dış referanslar yaratabilir.

Mümkünse, nesneleri üç bölümlü adlandırma yerine iki bölümlü adlandırma (schema.object) kullanarak modelleyin; hatta aynı depo içindeki kendine referanslar için bile. Bu gelenek, istemci araçları arasında tutarlılığı artırır ve üç bölümlü referansların getirdiği belirsizlikten kaçınır.

Git repository içinde tarihsiz .sqlproj

Git deposu, eski Microsoft.Build.Sql bir SDK sürümüne referans veren bir .sqlproj dosya içerebilir. Eski SDK, sütunlar CLUSTER BYve gibi yeni Fabric Data Warehouse sözdizimlerini IDENTITY tanımıyor.

Bu sorun, depo mevcut tanım formatına geçmeden önce içeriği taahhüt edilmiş depoları etkiler. Güncel olmayan bir .sqlproj dosyasına yol açan en yaygın durumlar şunlardır:

  • Yeni bir çalışma alanını mevcut bir depoya bağlamak. Depo, orada bulunan her şeyden oluşturulur.
  • Yeni bir çalışma alanına açılıyorum.
  • Git'ten silinmiş bir depoyu geri yüklemek.
  • Depo mevcut tanım formatına geçtikten hemen sonra Git'ten senkronizasyon, diğer yönde senkronizasyon başlamadan önce.

Mevcut tanım formatına taşınmayan depolar etkilenmez, çünkü eski proje dosyası inşa için kullanılmaz.

.sqlproj SDK sürümü nasıl doğrulanır

Depodaki depo dosyasını .sqlproj açın ve XML'de SDK sürümünü kontrol edin:

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

Mevcut Microsoft'un gerisinde olan bir versiyon. Build.Sql paket sürümü, güncel olmayan bir proje dosyasını gösterir. Örneğin, sizin versiyonunuz 'de 'de 0.1.başlarsa. Daha fazla bilgi için bkz. Microsoft. Build.SQL ve şablon sürümleri.

.sqlproj SDK sürümünü güncelleme seçeneği A: önce depoyu Git'e senkronize et

Eğer depo zaten çalışma alanında varsa ve sağlıklıysa, çalışma alanından Git'e commit yapın, sonra diğer yöne senkronize edin. Bu işlem, proje dosyasını mevcut SDK sürümüyle yeniden oluşturur ve ardından Git'ten senkronizasyon normal şekilde çalışır.

Bu seçenek, mevcut olduğunda tercih edilir, çünkü sadece SDK niteliğini değil, tüm tanımı günceller.

Bu seçeneğin çalışması için depo zaten mevcut tanım formatında olmalıdır. Eğer değilse, önce Fabric Git panelinde yükselt, sonra Git'e commit edin. Hala eski tanım formatında olan bir depodan commit yapmak, eski formatı depoya geri yazar ve SDK sürümünü yenilemez, böylece bir sonraki senkronizasyon aynı şekilde başarısız olur. Eğer yükseltme yapamazsanız, onun yerine Düzeltme seçeneği B'yi kullanın.

.sqlproj SDK sürümünü güncelleme seçeneği B: .sqlproj dosyasını doğrudan Git'te güncelle

Ambar hedef çalışma alanında henüz bulunmadığında, örneğin yeni bir çalışma alanı mevcut bir depoya bağlarken, dallanırken veya silinmiş bir depoyu geri getirirken bu seçeneği kullanın. Bu durumlarda senkronize edilecek bir depo yoktur, bu yüzden düzeltme seçeneği A mevcut değildir.

Dosyayı .sqlproj en son Microsoft'u kullanmak için dosyayı düzenleyin. Build.SQL paket sürümü ve değişikliği kabul et. Örneğin:

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

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

Tek başına bir dışa aktarma veya diferensi çalıştırmak proje dosyasını güncellemez. Dosya yalnızca çalışma alanından Git'e commit tamamlandığında veya manuel düzenleme yaptığınızda yeniden yazılır.

Başka bir depodaki iki veya daha fazla tabloya referans veren nesnelerdeki niteliksiz sütunlar

T-SQL sorgularında sütunlara atıfta bulunurken her zaman tablo aliaslarını sağlayın ve kullanın.

  • Bir T-SQL sorgusu başka bir depodaki iki veya daha fazla tabloya referans verdiğinde, derleme belirli bir tabloya tablo aliası olmadan yazılmış bir sütunu doğrulayamaz. Bu belirsizliğin var olması için tabloların aynı sütun adını paylaşması gerekmiyor. Bu belirsizlik doğrulama yapısında da var.
  • Bu belirsizlik, aynı ifade gövdesi içinde başka bir depodaki iki veya daha fazla tabloya referans veren nesneler içindeki T-SQL sorgularını etkiler.
  • Bu belirsizlik, başka bir depodaki sadece bir tabloya referans veren nesneler içindeki T-SQL sorgularını etkilemez, çünkü tek bir kaynakla arasında belirsizlik olacağı bir şey yoktur.
  • Bu belirsizlik, tamamen tek bir depoda kalan T-SQL sorgularını etkilemez.

Aşağıdaki örnekte, yalnızca fieldinfofiname, vardır, yani SQL geçerlidir ve depoya karşı doğru çalışır, ancak doğrulama derlemesinde belirsizlik vardır.

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

Etkilenen nesnedeki her sütun referansına bir tablo alias ekleyin:

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

Şema isimlerinin tutarsız büyük harflerle kullanılması

Deponuz, büyük harf duyarsız bir derleme kullanabilir, yani sales ve Sales aynı şemadır, ancak scriptleriniz farklı yerlerde her iki şekilde yazabilir. Küçük harf duyarsız veritabanları bunu her zaman kabul etmiştir, bu yüzden tutarsızlık genellikle uzun süredir ve zararsızdır.

Scriptleriniz başka bir deponun aynı şemasında iki veya daha fazla farklı nesneye referans verdiğinde ve her referansta o şemayı farklı şekilde yazdığında, derleme her yazım için bir CREATE SCHEMA ifade üretir. Bu sorun yalnızca başka bir depoya referans veren ve küçük harf duyarsız bir derleme kullanan depoları etkiler.

  • Varsayılan olarak, Fabric'teki depolar , küçük harf duyarlı bir derleme kullanırLatin1_General_100_BIN2_UTF8. Küçük harf hassasiyetli depolar etkilenmez. O depolarda sales ve Sales iki farklı şemadır, ister niyetli olun ister yapmasanız.
  • Bir küçük harf duyarsızlığı olan bir veritabanı hem sales de Sales. Kopya sadece SQL metninizdeki farklı yazımlardan kaynaklanır.

Depo derlemesini ve dosyada .sqlproj belirtilenleri ModelCollation kontrol edin. (küçük harf duyarsız) veya CS (küçük harf duyarlı) ifadelerine CI bak.

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

Düzelt

Depo nesnesi tanımlarınızda tutarsız şema adı büyük harfle kullanımını belirlemek için, hatada adı geçen şemanın tüm betiklerindeki büyük harflerini karşılaştırın. Aynı şemaya yalnızca duruma göre farklı olan iki çapraz depo referansı arayın.

Her yerde tutarlı bir büyük harf kullanın, referans edilen depodaki gerçek şema adıyla eşleştirin. Örneğin, sadece Sales veya sadece 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];

Bu sorunu, iki farklı nesneye ve iki farklı şema büyük harfine sahip olduğunda karşılaşırsınız. Aynı nesneye farklı büyük harflerle iki referans doğru şekilde katlanır ve başarısız olmaz.

Sütun sıralama

Bir sütunun maddesi, COLLATEdeponun varsayılan derlemesiyle aynı derlemeyi açıkça belirtiyorsa, Fabric'in şema çıkarımı (DacFx tabanlı) açık derlemeyi, hiç belirtmemeye eşdeğer olarak kabul eder. Bu durumda:

  • Açık COLLATE cümle, Git deposundan çıkarılan öğe tanımında görünmez.
  • Sütun, Git Değişiklikleri, Güncellemeler veya dağıtım boru hattı karşılaştırmalarında fark olarak görünmez, çünkü deponun varsayılan derlemesinden etkili bir fark yoktur.

Yalnızca deponun varsayılan derlemesinden farklı olan sütunlar, kaynak kontrolünde açık COLLATE bir madde tutar ve sadece bu sütunların derlemesindeki değişiklikler farklılık olarak görünür.

Örneğin, bir depoyu ele alalım; onun derlemesi şöyledir: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 açık bir toplama yoktur ve deponun varsayılan koleksiyonunu devralır.
  • LastNameBin Deponun varsayılan derlemesinden farklı açık bir derleme vardır, bu yüzden çıkarılan tanımda korunur ve değiştiğinde karşılaştırmalarda her zaman görünür.
  • Email deponun varsayılan derlemesine karşılık gelen açık bir derleme vardır. Madde COLLATE T-SQL'de bulunsa da, Git tarafından çıkarılmış tanımda veya Git veya dağıtım boru hattı karşılaştırmalarında görünmez, çünkü varsayılan olarak eşdeğerdir.

Tekrarlanan aday nesnelerle belirsiz sütun hataları

Git'ten commit veya güncelleme, aday listesinde bir :: ayrıcatıcı bulunan belirsiz bir sütun hatasıyla başarısız olabilir, örneğin:

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

Ayırıcı, :: bu hatayı, başka bir depodaki iki veya daha fazla tabloya referans veren nesnelerdeki niteliksiz sütunlarda tanımlanan gerçek belirsizlikten ayırır. Tablo takma adı eklemek sorunu çözmez çünkü takma ad aday listesinde görünür ve hata yine de devam eder.

  1. Öncelikle, bu iki yaygın nedeni ekarte edin:

    • Gerçekten eksik ya da yanlış adlandırılmış bir nesne. Aynı commit veya güncelleme de belirli bir eksik nesneye çözüm bulmamış bir referans bildiriyorsa, örneğin SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable], önce o referansı düzeltin. Adaylar :: genellikle onunla birlikte geçiyor.
    • Gerçekten belirsiz bir köşe. Eğer niteliksiz bir sütun, her ikisi de aynı isimde bir sütun ortaya çıkaran iki kaynağın birleşimi üzerine seçilirse, sütunu tablo aliasıyla nitelendirmek için nitelendirilir, örneğin a.[NCESID]. SQL Server bu sorguyu da reddeder, yani bu sadece Git entegrasyonuna özgü değildir.

  2. Eğer referans edilen her nesne varsa ve hiçbir sütun gerçekten belirsiz değilse, :: adaylar Git'ten yapılan commitler ve güncellemeler sırasında çalışan doğrulamada bilinen bir sorundur ve ürün ekibi tarafından takip edilir. Şu geçici çözümleri deneyin, sırayla:

    1. İç CTE'ler ve türeme tabloları açık bir sütun listesiyle değiştirin SELECT * .
    2. Görüşü bölerek her belirsiz kaynağın kendi görüşünde tanımlanmasını sağlayın ve temel sorguyu tekrarlamak yerine o görüşe referans verin.
    3. Aynı ifadede başka dinamik olarak şekillenmiş bir kaynağa katılmaktan OPENROWSET(BULK ...) kaçının.

Eğer bunların hiçbiri hatayı çözmezse, hatada adı geçen nesnenin tanımını toplayın ve destek talebi açın. Dağıtım boru hatlarına özgü sınırlamalar için bkz. Sınırlamalar.

İlgili içerik

  • Last updated on