Показать сообщение отдельно
Старый 16.04.2019, 02:39   #5  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Logger Посмотреть сообщение
А есть инфа почему так сделали? Юнит тесты неверно работали?
Мне кажется, как раз юнит-тесты все эти годы отрабатывали на ура, и косяки вылезли лишь в реальных проектах. Вроде автор пишет, почему изначально отказ от обрезания значений по EDT был рискованным шагом: допустим, есть у тебя в базе клиентская группа с кодом '0123456789', и пишешь ты код вида
X++:
CustGroup   custGroup;
CustGroupId custGroupId = '0123456789abcdefghij'; // допустим, извне пришло длинное значение
select firstonly custGroup where custGroup.CustGroup == custGroupId;
if (custGroup.CustGroup == custGroupId)
{
    info('Bingo!');
}
В AX2012 и ранее у тебя случается Bingo! Код прекрасно находит запись в CustGroup с кодом '0123456789', потому что длинное значение обрезается на присваивании строковой переменной, и в СУБД уходит параметр SQL-запроса "нужной" длины. А вот в D365O у тебя этот код ничего не находит, потому что в СУБД уходит строка 20 символов, которая никогда не окажется равна полю nvarchar(10).