Kako iz storitve OData nastane relacijski model ODBC

graph TD
    M["$metadata (CSDL)"] -->|"ob prvi uporabi povezave"| R["Model gonilnika: množice, stolpci, ključi, anotacije"]
    R --> K["Katalog za aplikacijo: SQLTables, SQLColumns, SQLStatistics"]
    R --> P["Prevod stavka v zahtevo OData"]
    P -->|"HTTP"| A["Odgovor JSON"]
    A --> E{"Razvrstitev odgovora"}
    E -->|"zbirka value"| Z["Vrstice: lastnost dodeljena stolpcu po imenu"]
    E -->|"@odata.nextLink"| F["naslednja stran"]
    E -->|"error"| D["Diagnostični zapisi"]
    E -->|"druge anotacije"| I["preskočeno"]

Slika: Gonilnik pomen vsakega elementa izpelje iz dokumenta metapodatkov in vrste zahteve, ne iz oblike JSON. Razvrščanje odgovorov opisuje stran Kako gonilnik razvršča in javlja odgovore.

OData podatke opisuje kot entitete s tipi, ključi, gnezdenimi vrednostmi in razmerji; ODBC pozna samo tabele iz vrstic in stolpcev s tipom SQL. Gonilnik zato preslika samo tisti del modela OData, ki ga je mogoče brez izgube pomena prikazati kot tabelo, preostanek pa izpusti tako, da je to razvidno. Ta stran za vsako vrsto elementa navaja, kaj gonilnik iz njega naredi. Ta stran je podlaga za vse, kar opisuje stran Podprti SQL: rezultatu lahko zaupate šele, ko je jasno, kateri stolpec ustreza kateri lastnosti.

• Množica entitet je tabela, lastnost s preprostim tipom je stolpec, ključ tipa entitete je primarni ključ.
• Tip pride iz $metadata, ne iz JSON: število, ki prispe kot besedilo, ostane število; vrednost, ki se ne ujema z deklariranim tipom, je napaka, ne tiha pretvorba.
• Kar ni mogoče prikazati kot stolpec, vidno manjka: kompleksne vrednosti, zbirke in razmerja se ne pojavijo, namesto da bi bili sploščeni ali ponujeni kot besedilo.
• Krmilni podatki niso podatki: @odata.nextLink krmili listanje, druge anotacije odgovora nikoli ne postanejo stolpci.

Gonilnik prebere $metadata enkrat za vsako povezavo, ob njeni prvi uporabi. Osnova je format CSDL XML iz OData 4.0/4.01 (glejte Standardi in specifikacije).

Imena. Gonilnik množice in stolpce javi pod imeni iz $metadata. Ime, ki ga je storitev kodirala z _xHHHH_, dekodira, kolikor lahko Access rezultat obdela; glejte Ime polja je prikazano kodirano ali povezovanje ne uspe.

Pogledi. OData pogleda ne razlikuje od tabele; vsaka množica se pojavi kot TABLE.

Bralna zahteva vrne zbirko: objekt JSON s poljem value. Gonilnik njegove dele razvrsti takole:

Pretvorba po deklariranem tipu. Vrednost se bere po svojem tipu v $metadata, ne po obliki JSON: "12.50" je za stolpec Edm.Decimal število 12,50, "NaN" za Edm.Double posebna vrednost. Če se vrednost ne ujema s tipom, se branje prekine s sporočilom “Vrednost stolpca … se ne ujema z napovedanim tipom …”; gonilnik ne ugiba drugega tipa.

Štetje. COUNT(*) se pošlje na …/$count; odgovor je število kot besedilo, ne zbirka.

Pri spreminjanju in brisanju gonilnik vrednost za If-Match tvori sam iz stolpca, ki ga navaja Core.OptimisticConcurrency in ga Access pošlje kot pogoj: binarna vrednost postane W/"<Base64>", besedilo, ki se začne z W/, ostane takšno, kot je, vsako drugo besedilo pa postane W/"<besedilo>". Storitev mora torej sprejeti ETag te oblike; @odata.etag iz odgovora gonilnik ne bere. Podatkovni prehod Wkl.Data.Gateway to obliko sprejme; pri drugi storitvi to preverite pred uporabo.

Ni preslikano pomeni: gonilnik elementa ne prikaže in deluje naprej brez njega. Pri tem ne javi ne napake ne opozorila. Aplikacija manjkajoče dele prepozna samo po tem, da stolpca ali tabele ni v katalogu. Kjer je tak del potreben, na primer spoj prek razmerja ali klic funkcije, je na voljo prepustna pot, če jo storitev podpira.

• Kako gonilnik razvršča in javlja odgovore – uspeh, napaka, opozorilo, nepričakovan odgovor
• Kako gonilnik prevaja stavke – od SQL do zahteve
• Ubežne klavzule in podatkovni tipi – preslikava tipov podrobno
• Zahteve za storitev OData – kaj mora storitev podpirati