Блог

С Table.NestedJoin JoinKind.FullOuter , a null может быть записано в столбцы, когда в правой таблице «ключ» есть значение, которого нет в левой таблице «ключ».

Однако, в отличие от значения null, которое находится в левой таблице, поскольку ячейка пуста, это созданное значение null не соответствует формуле = True [column] = null .

Например:

Таблица 1
Обратите внимание на нуль в строке 3

Таблица 2

Объединенный Стол
Значение null в строке 5 было создано в результате объединения

Пользовательский столбец
добавлено с формулой =[A]=null
обратите внимание на различные результаты для null

MCode для воспроизведения вышесказанного

 let
    Source1 = Table.FromRecords({
        [A="a"],
        [A="b"],
        [A=null],
        [A="c"]
    }),
    type1 = Table.TransformColumnTypes(Source1,{"A", type text}),
    Source2 = Table.FromRecords({
        [A="c"],
        [A="d"]
    }),
    type2 = Table.TransformColumnTypes(Source2,{"A", type text}),

    combo = Table.NestedJoin(type1,"A",type2,"A","joined",JoinKind.FullOuter),
    #"Added Custom" = Table.AddColumn(combo, "Custom", each [A]=null)
in
    #"Added Custom"
 

Мы были бы признательны за разъяснения и предложения относительно того, как с этим бороться.

Редактирование В дополнение к вышесказанному, выполнение a Replace также заменит null только строку 3, а не null строку 5. Кажется, в этих двух нулях есть что-то другое.

Примечание: Если я разверну таблицу, значение null в столбце A теперь будет проверяться правильно.

Задав тот же вопрос на форуме вопросов и ответов Microsoft, я указал на возможность проблемы с моделью оценки запросов питания, а также на эту статью о ленивой оценке и сворачивании запросов в Power BI/Power Query.

Принудительно оценивая таблицу с Table.Buffer помощью , оба значения null теперь ведут себя одинаково.

Так:

 let
    Source1 = Table.FromRecords({
        [A="a"],
        [A="b"],
        [A=null],
        [A="c"]
    }),
    type1 = Table.TransformColumnTypes(Source1,{"A", type text}),
    Source2 = Table.FromRecords({
        [A="c"],
        [A="d"]
    }),
    type2 = Table.TransformColumnTypes(Source2,{"A", type text}),

//Table.Buffer forces evaluation
    combo = Table.Buffer(Table.NestedJoin(type1,"A",type2,"A","joined",JoinKind.FullOuter)),

//IsItNull now works
    IsItNull = Table.AddColumn(combo, "[A] = null", each [A] = null)
  in
    IsItNull
 

Это также, по-видимому, тот случай, который try ... otherwise также заставит провести оценку. Так что вместо стола.Буфер, также работает следующее:

     ...
    combo = Table.NestedJoin(type1,"A",type2,"A","joined",JoinKind.FullOuter),
//try ... otherwise seems to force Evaluation
    IsItNull = Table.AddColumn(combo, "[A] = null", each try [A] = null otherwise null)
 

Очень интересный случай. Действительно, поведение последнего значения null противоречит здравому смыслу в большинстве возможных реализаций. Если вы хотите получить одинаковое поведение для обоих типов нулей, попробуйте этот подход:

 = Table.AddColumn(combo, "test", each [A] ?? 10)
 

Довольно интересно, что аналогичный код не работает:

 = Table.AddColumn(combo, "test", each if [A] = null then 10 else [A])
 

Более того, если мы хотим улучшить предыдущий код, используя первый синтаксис, мы все равно получим неожиданный результат (10 вместо 20 для последнего нуля).:

 = Table.AddColumn(combo, "test", each if [A] = null then 10 else [A] ?? 20)
 

Любопытно, что применение оператора ?? также устраняет проблему с начальным столбцом. Теперь в столбце есть обычные нули:

 = Table.AddColumn(add, "test2", each [A] = null)
 

Поэтому, если нам не нужны никакие вычисления и мы просто хотим исправить недопустимые нули, мы можем использовать такой код:

 = Table.TransformColumns(combo, {"A", each _ ?? _})
 

Столбец не имеет значения, и для объединенного столбца результат тот же самый:

 transform = Table.TransformColumns(combo, {"joined", each _ ?? _}),
add = Table.AddColumn(transform, "test", each [A] = null)