У меня есть внешняя таблица на моем SQL 2019 сервере; связан с базой данных космоса через polybase. База данных содержит ряд различных типов документов с различными схемами JSON. Они видны в проводнике данных azure, и тот, с которым я борюсь, выглядит примерно так:
{
"_id" : ObjectId("fb5ab7f8443c4d0298e19e51"),
"type" : "myType",
"dateRange" : {
"start" : {
"$date" : 1581453600000
},
"end" : {
"$date" : 1581454800000
}
},
"External1Id" : ObjectId("093d1319314d479bbc03bc69"),
"External2Id" : ObjectId("9af08a9eee264fd5bfceb4fd"),
"created" : {
"$date" : 1581366945000
},
"updated" : {
"$date" : 1581366945000
}
}
Я могу создать внешнюю таблицу и связать ее с большинством полей; но я не могу получить второе и третье поля идентификатора, чтобы получить подтверждение проверки схемы. Схема говорит, что в таблице 181 столбец. У них есть уникальные имена в документе.
CREATE EXTERNAL TABLE dbo.tblMyObjects(
_id NVARCHAR(128) NOT NULL
, type NVARCHAR(128) NULL
, dateRange_start DATETIME2 NULL
, dateRange_end DATETIME2 NULL
, created DATETIME2 NULL
, updated DATETIME2 NULL) WITH(DATA_SOURCE = CosmosDB, LOCATION = N'mydocumentdb.qa');
GO
Возвращенная ошибка:
xxyy was not found in the external table
Если я создаю внешнюю таблицу с рекомендованной схемой; только столбцы в моей таблице выше заполнены данными. Поля идентификаторов, использующие Nvarchar, следуют рекомендации в документе сопоставления типов на боле.)
книги онлайн нивелирующие заметки говорят, что вызывать поля после первого элемента в JSON; но в этих документах такого нет, поэтому я ожидал, что добавление External1Id nvarchar (128) даст мне данные. Вместо этого я получаю ошибку, не найденную во внешней таблице; также пытались использовать max для того же результата)
Валидатор схемы отклоняет это как поле; и в данных нет альтернативы. Имею ли я право ожидать, что имя здесь будет External1Id или оно должно быть чем-то другим? Есть ли способ отладить то, что здесь происходит, или какие-либо рекомендации по отображению ошибочных столбцов в схеме polybase?