Git-integraation vianetsintä varastokehityksessä

Koskee:✅ Varasto Microsoft Fabricissa

Tässä artikkelissa käsitellään vianetsintäaiheita Fabric tietovarasto kehittämiseen ja käyttöönottoon Fabric:n sisäänrakennetun Git-integraation avulla.

Important

Tämä ominaisuus on esikatselutilassa.

Viittaukset varaston omiin esineisiin käyttämällä kolmiosaista nimeä

Objekti voi viitata toiseen objektiin samassa varastossa käyttämällä kolmiosaista nimeä, [warehouse_name].[schema_name].[object_name].

Kolmiosainen nimeäminen on tarkoitettu viittaamaan toiseen varastoon. Kun tietokantaosa nimeää nykyisen varaston, build käsittelee viittauksen ulkoisena, ja objekti määritellään mallissa kahdesti.

Poista tietokanta-osa varaston omiin objekteihin liittyvistä viittauksista:

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

Vain viittaukset varaston omiin esineisiin täytyy muuttaa. Aidot ristiintietokantaviittaukset muihin varastoihin, kuten [Other_Warehouse].[Sales].[Orders], ovat tuettuja ja niiden tulisi pysyä as-is.

Important

Käytä kolmiosaista nimeämistä (database.schema.object) vain varasto- tai SQL-analytiikan päätepistereferensseihin, älä viittaamaan objekteihin saman varaston sisällä. Objektien itseviittaaminen samassa varastossa käyttämällä kolmiosaista nimeämistä ei ole tavanomaista mallinnuskäytäntöä, ja se voi aiheuttaa tahattomia ulkoisia viittauksia.

Mahdollisuuksien mukaan mallintaa objekteja käyttämällä kaksiosaista nimeämistä (schema.object) kolmiosaisen sijaan, jopa itseviittauksille saman varaston sisällä. Tämä käytäntö parantaa johdonmukaisuutta asiakastyökalujen välillä ja välttää kolmiosaisten viittausten aiheuttaman epäselvyyden.

Un-of-date .sqlproj Git repository

Git-repositoriossa voi olla .sqlproj tiedosto, joka viittaa vanhempaan Microsoft.Build.Sql SDK-versioon. Vanhempi SDK ei tunnista uudempia Fabric tietovarasto-syntaksia, kuten IDENTITY sarakkeita ja CLUSTER BY.

Tämä ongelma koskee tietovarastoja, joiden sisältö on tehty ennen varaston siirtymistä nykyiseen määritelmämuotoon. Yleisimmät tilanteet, jotka johtavat vanhentuneeseen .sqlproj-tiedostoon, ovat:

  • Uuden työtilan yhdistäminen olemassa olevaan tietovarastoon. Varasto rakennetaan siitä, mitä siellä on sidottu.
  • Laajentamassa uutta työtilaa.
  • Poistatun varaston palauttaminen Gitistä.
  • Synkronointi Gitistä heti sen jälkeen, kun varasto siirtyi nykyiseen määrittelymuotoon, ennen kuin synkronointi toiseen suuntaan on tehty.

Varastot, joita ei ole siirretty nykyiseen määrittelymuotoon, eivät muutu, koska vanhempaa projektitiedostoa ei käytetä rakentamiseen.

Kuinka vahvistaa .sqlproj SDK -versio

Avaa varaston .sqlproj tiedosto arkistossa ja tarkista SDK-versio XML:stä:

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

Versio, joka on nykyisen Microsoftin takana. Build.SQL-pakettiversio tarkoittaa vanhentunutta projektitiedostoa. Esimerkiksi, jos versiosi alkaa .0.1. Lisätietoja löytyy osoitteesta Microsoft. Build.SQL- ja Templates-julkaisut.

Päivitä .sqlproj SDK-versio vaihtoehto A: synkronoi varasto ensin Gitiin

Jos varasto on jo olemassa työtilassa ja kunnossa, commit työtilasta Gitille ennen synkronointia toiseen suuntaan. Tämä toiminto generoi projektitiedoston uudelleen nykyisellä SDK-versiolla, minkä jälkeen synkronointi Gitistä toimii normaalisti.

Tämä vaihtoehto on suositeltava, jos se on saatavilla, koska se päivittää koko määritelmän eikä pelkästään SDK-attribuutin.

Varaston täytyy jo olla nykyisessä määritelmämuodossa, jotta tämä vaihtoehto toimii. Jos ei ole, päivitä se ensin Fabric Git -paneelissa ja sitten sitoutuu Git-paneeliin. Jos sitoudut varastosta, joka on vielä vanhemmassa määritelmäformaatissa, vanha muoto kirjoitetaan takaisin repositorioon eikä SDK-versiota päivitä, joten seuraava synkronointi epäonnistuu samalla tavalla. Jos et voi päivittää, käytä korjausvaihtoehtoa B .

Päivitä .sqlproj SDK-versio vaihtoehto B: päivitä .sqlproj-tiedosto suoraan Gitissä

Käytä tätä vaihtoehtoa, kun varastoa ei vielä ole kohdetyötilassa, esimerkiksi kun yhdistät uuden työtilan olemassa olevaan tietovarastoon, haaraudut tai palautat poistettua varastoa. Näissä tapauksissa ei ole varastoa, josta synkronoida, joten korjausvaihtoehto A ei ole käytettävissä.

Muokkaa .sqlproj tiedostoa arkistossa käyttääksesi uusinta Microsoft-sovellusta. Build.SQL-pakettiversio ja sitoudu muutokseen. Esimerkkejä:

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

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

Viennin tai diffin ajaminen yksinään ei päivitä projektitiedostoa. Tiedosto kirjoitetaan uudelleen vain, kun työtilasta Gitiin tehty commit valmistuu tai kun muokkaat sitä manuaalisesti.

Määrittelemättömät sarakkeet objekteissa, jotka viittaavat kahteen tai useampaan taulukkoon toisessa varastossa

Anna ja käytä aina taulukkoaliakseja, kun viitataan sarakkeisiin T-SQL-kyselyissä.

  • Kun T-SQL-kysely viittaa kahteen tai useampaan tauluun toisessa varastossa, rakennelma ei voi validoida saraketta, joka on kirjoitettu ilman taulun aliasta tiettyyn tauluun. Taulukoiden ei tarvitse jakaa sarakkeen nimeä, jotta tämä epäselvyys olisi olemassa. Tämä epäselvyys on olemassa validointirakenteessa.
  • Tämä epäselvyys vaikuttaa T-SQL-kyselyihin objekteissa, jotka viittaavat kahteen tai useampaan taulukkoon toisessa varastossa saman lauseen rungossa.
  • Tämä epäselvyys ei vaikuta T-SQL-kyselyihin objekteissa, jotka viittaavat vain yhteen taulukkoon toisessa varastossa, koska yhden lähteen kanssa ei ole mitään epäselvää.
  • Tämä epäselvyys ei vaikuta T-SQL-kyselyihin, jotka pysyvät kokonaan yhdessä varastossa.

Seuraavassa esimerkissä on fieldinfovain finame , joten SQL on kelvollinen ja toimii oikein varastoa vastaan, mutta validointiversiossa on epäselvyys.

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

Lisää taulukkoalias jokaiseen sarakeviittaukseen kyseisessä objektissa:

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

Skeemanimien epäjohdonmukainen isojen kirjainten käyttö

Varastosi voi käyttää kirjainkoon sitoutumatonta kokoamista, joten sales ja Sales ovat sama skeema, mutta skriptisi voivat kirjoittaa sen molempiin suuntiin eri kohdissa. Kirjainkoon sensitunteettomat tietokannat ovat aina hyväksyneet tämän, joten epäjohdonmukaisuus on yleensä pitkään jatkunut ja harmiton.

Kun skriptisi viittaavat kahteen tai useampaan eri objektiin samassa toisen varaston skeemassa ja kirjoittavat kyseisen skeeman eri tavalla jokaisessa viitteessä, build luo CREATE SCHEMA lauseen jokaiselle kirjoitusasulle. Tämä ongelma koskee vain varastoja, jotka viittaavat toiseen varastoon ja käyttävät kirjainkoon perustumatonta vertailua.

  • Oletuksena Fabric-varastot käyttävät Latin1_General_100_BIN2_UTF8, kirjainkoon sensitiivistä vertailua. Kirjaimiin sensitiiviset varastot eivät ole vaikuttuneita. Näissä varastoissa sales on Sales kaksi eri skeemaa, halusitpa tai et.
  • Kirjainkoon sitoutumaton tietokanta ei voi sisältää sekä sales että Sales. Kaksoiskappale tulee vain SQL-tekstisi eri kirjoitusasuista.

Tarkista varaston vertailu ja tiedostossa mainitutModelCollation..sqlproj Etsi CI (kirjainkoiton herkkyys) tai CS (kirjainkoon herkkä).

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

Korjaus

Tunnistaaksesi epäjohdonmukaiset skeeman nimen isot kirjaimet varaston objektimäärittelyissä, vertaa virheessä mainitun skeeman isot kirjaimet kaikissa skripteissäsi. Etsi kahta ristivarastoviittausta samaan skeemaan, jotka eroavat vain tapauksissa.

Käytä kaikkialla yhtä johdonmukaista isoa kirjainta, vastaten viitatun varaston skeeman nimeä. Esimerkiksi käytä vain Sales tai vain 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];

Tämä ongelma ilmenee, kun sinulla on kaksi eri objektia, joilla on kaksi eri skeeman isotusta. Kaksi viittausta samaan objektiin eri isolla kirjaimella on taitettu oikein eivätkä epäonnistu.

Sarakkeiden yhdistäminen

Jos sarakkeen COLLATE lauseke määrittelee saman kokoamisen kuin varaston oletuskokoilu, Fabric'n skeeman poimiminen (DacFx-pohjainen) käsittelee eksplisiittisen kokoamisen vastaisena siihen, ettei sitä ole määritelty lainkaan. Tässä tapauksessa:

  • Eksplisiittistä COLLATE lauseketta ei esiinny Git-repositoriosta poimitussa kohteen määritelmässä.
  • Sarake ei näy erotuksina Git-muutoksissa, päivityksissä tai käyttöönoton putkistovertailuissa, koska varaston oletuskokoukseen ei ole tehokasta eroa.

Vain ne sarakkeet, joiden vertailu poikkeaa varaston oletuskokouksesta, säilyttävät selkeän COLLATE lausekkeen lähdekoodin hallinnassa, ja erotuksina näkyvät vain muutokset näiden sarakkeiden vertailussa.

Esimerkiksi tarkastellaan varastoa, jonka vertailu on 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 ei ole eksplisiittistä vertailua ja perii varaston oletuskokouksen.
  • LastNameBin sillä on eksplisiittinen vertailu, joka poikkeaa varaston oletusvertailusta, joten se säilyy poimussa määritelmässä ja näkyy aina vertailuissa, jos se muuttuu.
  • Email sisältää eksplisiittisen kokoamisen, joka vastaa varaston oletuskokoamista. Vaikka lauseke COLLATE esiintyy T-SQL:ssä, se ei esiinny Git-purkatussa määritelmässä tai Git- tai käyttöönottoputkien vertailuissa, koska se vastaa oletusta.

Epäselvät sarakevirheet päällekkäisillä ehdokasobjekteilla

Sitominen tai päivittäminen Gitistä voi epäonnistua epäselvän sarakkevirheen kanssa, jonka ehdokaslistalla on :: erotin, esimerkiksi:

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

Erotin :: erottaa tämän virheen aidosta epäselvyydestä, joka kuvataan Unqualified columns -sarakkeissa objekteissa, jotka viittaavat kahteen tai useampaan taulukkoon toisessa varastossa. Taulukon aliaksen lisääminen ei ratkaise ongelmaa, koska alias näkyy ehdokaslistalla ja virhe jatkuu.

  1. Ensiksi sulje pois nämä kaksi yleisempää syytä:

    • Aidosti puuttuva tai väärin nimetty esine. Jos sama commit tai päivitys raportoi myös ratkaisemattoman viittauksen tiettyyn puuttuvaan objektiin, kuten SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable], korjaa kyseinen viittaus ensin. Ehdokkaat :: yleensä pääsevät läpi sen mukana.
    • Aidosti monitulkintainen kolumni. Jos määrittelemätön sarake valitaan kahden lähteen liitoksen sijaan, jotka molemmat paljastavat samannimisen sarakeen, määrittele sarake sen taulukkoaliaksella, esimerkiksi a.[NCESID]. SQL Server hylkäisi tämän kyselyn myös, joten se ei ole sidottu Git-integraatioon.

  2. Jos jokainen viitattu olio on olemassa eikä mikään sarake ole aidosti epäselvä, ehdokkaat :: ovat tunnettu ongelma vahvistuksessa, joka suoritetaan committien ja päivitysten aikana Gitistä, ja jota tuotetiimi seuraa. Kokeile näitä kiertoteitä järjestyksessä:

    1. Korvaa SELECT * sisäiset CTE:t ja johdetut taulukot eksplisiittisellä sarakelistalla.
    2. Jaa näkymä niin, että jokainen epäselvä lähde määritellään omassa näkemyksessään, ja viittaa siihen näkymään sen sijaan, että toistaisit taustalla olevan kyselyn.
    3. Vältä liittymistä OPENROWSET(BULK ...) toiseen dynaamisesti muotoiltuun lähteeseen samassa lauseessa.

Jos mikään näistä ei ratkaise virhettä, kerää virheessä mainitun objektin määritelmä ja avaa tukipyyntö. Käyttöönottoputkiin liittyvät rajoitukset löytyvät kohdasta Rajoitukset.

Liittyvä sisältö

  • Last updated on