littleax: Dynamics 365 for Operations. Использование SysComputedColumn при создании представлений

[Blog bot]

Источник: http://littleax.blogspot.com/2017/11...perations.html
==============

SMART TALKS

Dynamics 365 for Operations


Использование SysComputedColumn при создании представлений

При построении разного рода отчетов, тем более в современной и модной технологии (охо-хо) Power BI мы сталкиваемся с вопросами производительности выборок. Еще один вариант использования, по View мы можем создать DataEntity а к DataEntity получить доступ уже по oData из внешней системы.



http://smart-talks.org/event/smart-talks-122/#r2

Источник: http://littleax.blogspot.com/2017/11...perations.html

[mazzy]

Смотрю я на видео с ужасом... и поверить своим глазам не могу.
Это ж какое поле открыли для SQL-инекций!
Даже древние движки форумов имеют более интеллектуальный SQL-враппер.

я поначалу подумал, что это доработка такая. нет. ЭТО в стандартной аксапте. и ЭТО используется.

И никаких инструментов ни для отладки ЭТОГО, ни для performance monitoring'а.


И при таких дырах в функционале они занимаются добавлением пользовательских полей. Господи, прости.
Лучше бы запросы сделали нормальные, раз уж выкинули разные СУБД.

=======================
к девушке - никаких претензий - норм рассказала о стандартном функционале.
и нормально про свой опыт работы с этим.

[trud]

Цитата:

Сообщение от mazzy

Смотрю я на видео с ужасом... и поверить своим глазам не могу.
Это ж какое поле открыли для SQL-инекций!
я поначалу подумал, что это доработка такая. нет. ЭТО в стандартной аксапте. и ЭТО используется.

И никаких инструментов ни для отладки ЭТОГО, ни для performance monitoring'а.

А можешь пояснить при чем тут SQL-инекции? этож не рантайм функции, делаешь метод, он при синхронизации создает поле во вью(полезно когда например одно поле Amount надо вывести в 2 - дебет и кредит). на производительность вроде тоже никак не должно влиять, это просто опрерации над полями текущего курсора, никаких возможностей более тут нет. для отладки просто смотришь определение view.
для АХ7 при использовании лицензий (ISV) это кстати вообще поломали, т.е. один вью основанный на полях другого вью при отключенных конфиг. ключах вызывает ошибку синхронизации и невозможности установки пакета, а если мы хотим лицензию поставлять отдельно, при наличии в решинии таких вложенных вью ничего не получится

[mazzy]

Цитата:

Сообщение от skuull

Привествуем в мире проектных бюджетов, там все работает на SQL магии, поэтому их лучше обходить стороной

Да-да.

И если кто-нибудь даже
Захочет, чтоб было иначе,
Бессильный и неумелый,
Опустит слабые руки,
Не зная, где сердце спрута
И есть ли у спрута сердце...

Цитата:

Сообщение от trud

А можешь пояснить при чем тут SQL-инекции? этож не рантайм функции, делаешь метод, он при синхронизации создает поле во вью

а какая разница, рантайм или не рантайм? какая разница до синхронизации или после, если иньекция неизбежно сработает?
если никаких проверок и экранирований не предусмотрено ни в "делаешь метод", ни в синхронизации?

[belugin]

Цитата:

Сообщение от mazzy

если никаких проверок и экранирований не предусмотрено ни в "делаешь метод", ни в синхронизации?

Проверок нет, а вот экранирование есть (см *literal*) просто в Add не надо экранировать, так как на вход получается уже готовое sql выражение (на что намекает слово expression, в качестве имени параметра). Прямой sql был всегда, тут сделали шажок вперед - набор утилит для его создания. Следующий шажок мог быть завернуть его в отдельный тип, чтобы случайно не смешать исходные данные и подготовленный SQL, дальше expression tree, LINQ и компиляция из подмножества X++.

Короче, не ужас-ужас-ужас

[mazzy]

оказывается ЭТО в 2012 добавили

[skuull]

Цитата:

Сообщение от mazzy

оказывается ЭТО в 2012 добавили

Привествуем в мире проектных бюджетов, там все работает на SQL магии, поэтому их лучше обходить стороной

[sukhanchik]

Цитата:

Сообщение от skuull

Привествуем в мире проектных бюджетов, там все работает на SQL магии, поэтому их лучше обходить стороной

Ну почему именно проектных? Вполне себе обычных ГКшных. С хранимыми процедурами. Об этом даже официальная дока написана

[skuull]

Цитата:

Сообщение от sukhanchik

Ну почему именно проектных? Вполне себе обычных ГКшных. С хранимыми процедурами. Об этом даже официальная дока написана

Давайте скажем так "Приветствуем в мире проектных бюджетов, там все работает на SQL магии, поэтому их лучше обходить стороной."

Ну потому что они к сердцу ближе и еще свежи воспоминания Но там местами пренебрегли даже computed columns, просто навалили SQL.

[sukhanchik]

Ну тогда уж и приведу скриншот с ГКшных бюджетов с их хранимыми процедурами, где одна процедура вызывает другую

[Raven Melancholic]

Просто интересно, чем рассчитанные затраты на ввод ComputedColumn в DAX2012 таким способом с точки зрения затрат (времени, денег) отличались от расширения движка запросов аксы вводом возможностей подзапросов в where, в полях, вводом алиасов для выбранных полей, указанием литералов в выборке и выражениях запроса и т.п.?
В DAX2009 ввели union (пусть достаточно ограничено) - никто же не умер.
Зачем нужны эти придумки вместо ввода поддержки давно проверенных подходов?

[Raven Melancholic]

Такое впечатление, что при покупке MS продукта либо было соглашение о том, что движок запросов трогать нельзя, либо исходный код этого движка не был передан, либо никто в этом движке не стал разбираться.

[belugin]

Цитата:

Сообщение от Raven Melancholic

Просто интересно, чем рассчитанные затраты на ввод ComputedColumn в DAX2012 таким способом с точки зрения затрат (времени, денег) отличались от расширения движка запросов аксы вводом возможностей подзапросов в where, в полях, вводом алиасов для выбранных полей, указанием литералов в выборке и выражениях запроса и т.п.?

Я думаю, что различия в трудоемкости большие - в одном слкчае надо сделать точку входа куда передавать строчку. В другом случае расковырять написанный давно на C++ движок чтобы все это обеспечить и ничего не сломать.