другой запрос определённого шага ? = Данные #"Переупорядоченные столбцы"
Добрый вечер, в запросе надо будет заменить слово let на [, а in .... на ]
речь про промежуточный шаг другого запроса? либо поместить этот шаг в мета-данные итогового шага, либо отказаться от конструкции let ... in, т.е. представить запрос в форме записи и ссылаться на соответствующее поле этой записи
У меня есть один запрос , в другом запросе мне нужно сослаться на определённый шаг предыдущего запроса. данные прислать не могу (( могу примерно сделать вымышленную таблицу, чтоб поняли, что требуется
НЕЛЬЗЯ сослаться на шаг запроса - варианты выше вам уже предложили
Не надо мету. Уже обсуждали, запрос выполнится ещё раз полностью в таком случае, это как минимум. Самое надёжное - сделать вилку из трех запросов - до нужного шага, далее два запроса ссылками на него. Ну или запись, монопенисуально, запись надо опять третьим запросом получать.
вот после этого мету внес в черный список... не знал но ведь в случае с тремя запросами, все шаги исходного запроса тоже будут выполнены 2 раза... я на самом деле обычно так: делаю полузапрос до условно "промежуточного шага" а в том запросе, в котором мне нужны оба результата (условно промежуточный и условно итоговый) ссылаюсь на первый запрос, делаю буфер и уже из буфера достаю сначала первый результат, а потом делаю остальные вычисления для получения второго результата
В идеальной картине мира добавление меты подразумевало бы, что при попытке ее извлечь умный PQ говорил бы: "мне не надо выполнять весь запрос, я просто выполню то, что нужно для меты". Если у нас есть запрос Q1 на 10 шагов, и в мету положили бы 5й, то запрос значения меты привел бы к выполнению 5 шагов. Это также требовало бы такой ситуации, что вместо значения запроса Q1, из которого мы забираем мету, мы бы имели promise значения запроса Q1, который promise и не реализовывался бы, так как мы его не хотим. Однако мы де-факто просим в функции Value.Metadata: дайте нам значение и извлеките из него метаданные. Чтобы дать значение, надо выполнить все шаги запроса Q1 (ведь мы присваиваем мету только на последнем этапе/шаге). Получается, что получение промежуточного шага требует выполнения всего запроса. Затем мы смотрим на метаданные, а там бац - запись. Пока у записи не запрашивали значение поля, вместо этого значения есть лишь promise значения поля. В итоге весьма вероятно, что в процессе вычисления результата меты нужно выполнить ещё раз те 5 шагов, на результат которых мы ссылаемся. В общем, при наличии запроса в 10 шагов, загружаемого в модель/лист, достать промежуточный шаг #5 стоит нам минимум 10 дополнительных шагов, а скорее всего, 10+5. Итого имеем 10+10+5, 25 шагов. Если же мы делаем стоп на шаге 5 и от него строим 2 запроса, один просто ссылкой и второй с остальными 5 шагами, то итог нам стоит 5+5 - первый запрос и просто 5 - второй. Итого 15. Даже если мы вдруг внезапно получим мету без доп. затрат (т.е. она будет заполнена в процессе расчёта значения, к которому её прицепили), то затраты будут 10+10, что все равно больше. Понятно, что дело не в числе шагов, а в трудоёмкости операций до и после вилки.
познавательно спасибо недавно видел статью, где описывалось как с помощью меты документировать пользовательскую функцию... выглядит конечно красиво, но реальная польза от этого для себя отсутствует... только для сторонних юзеров... ибо мне, в своей функции и комментария достаточно в чем еще может быть полезна мета?
ну например простое значение превратить в параметр )))
Обсуждают сегодня