Регистрация  |  Вход

Косяки с Decimal полями

Ну наконец-то появилась тема по Salesforce о которой хочется поведать. Случился такой случай от которого сломал весь мозг.

Написал простейщий триггер который должен найти Lead и Account по одному полю типа внешнего ключа. Поле и на Lead и на Account Decimal типа но ключи там обычные Integer. Мы же помним что в SF нет Integer полей. Зачем так сделано не спрашивайте - это пакетные поля от одного уважаемого пакета. В общем дело плевое получаем на вход Leads, получаем значение их поля и ищем по ним Accounts ну и дальше сопоставляем Lead -> Account по этому полю. Сделано, проверяем, работает. Отдаешь заказчику. В ответ - нифига не работает. Захожу проверить на Lead которого скинули, делаю Save - не работает. Что за фигня. Открываю Developer Console. Пишу так 2 строчки - SOQL + update - работает. Триггер запустился и все отработало. Захожу на UI, делаю апдейт Lead - не работает.

В общем дебажил дебажил (особенно весело когда это на проде) и выяснил такую классную вещь. Если триггер запускается из кода, то значение в поле выглядит вот так 731691, а триггер срабатывает из LWC то значение выглядит вот так 731691.0 И если использовать Map<Decimal, Account> то это оказывается разные ключи и 731691 != 731691.0

А ключи разные в Map<Decimal, Account> по всей видимости потому что эта мапа на самом деле хранится как Map<String, Account>, то есть ключ Decimal превращается в String. А выяснил я эту магию когда сам вручную решил избавиться от Decimal и преобразовать все в String перед использованием.

В итоге порешалось все преобразованием в Integer.

Выводы отсюда - для ключей в SF нисколько нельзя использовать Decimal поле. Мало того что столько гемора, так еще и на UI ваш ID выглядит вот так 731,691 - согласитесь как то уже не похоже на ID. Ну и в коде Decimal использовать только для вычислений а не для ID, ключей и прочей шляпы где нужна точность. Понимаю создателей пакета, они по ходу не профильные разрабы SF и в других базах данных это нормальная практика использовать колонки в таблицах с типом Integer в виде числовых ключей. Но это не про SF.
Ну наконец-то появилась тема по Salesforce о которой хочется поведать. Случился такой случай от которого сломал весь мозг.

Написал простейщий триггер который должен найти Lead и Account по одному полю типа внешнего ключа. Поле и на Lead и на Account Decimal типа но ключи там обычные Integer. Мы же помним что в SF нет Integer полей. Зачем так сделано не спрашивайте - это пакетные поля от одного уважаемого пакета. В общем дело плевое получаем на вход Leads, получаем значение их поля и ищем по ним Accounts ну и дальше сопоставляем Lead -> Account по этому полю. Сделано, проверяем, работает. Отдаешь заказчику. В ответ - нифига не работает. Захожу проверить на Lead которого скинули, делаю Save - не работает. Что за фигня. Открываю Developer Console. Пишу так 2 строчки - SOQL + update - работает. Триггер запустился и все отработало. Захожу на UI, делаю апдейт Lead - не работает. 

В общем дебажил дебажил (особенно весело когда это на проде) и выяснил такую классную вещь. Если триггер запускается из кода, то значение в поле выглядит вот так 731691, а триггер срабатывает из LWC то значение выглядит вот так 731691.0 И если использовать Map<Decimal, Account> то это оказывается разные ключи и 731691 != 731691.0 :surprised:

А ключи разные в Map<Decimal, Account> по всей видимости потому что эта мапа на самом деле хранится как Map<String, Account>, то есть ключ Decimal превращается в String. А выяснил я эту магию когда сам вручную решил избавиться от Decimal и преобразовать все в String перед использованием. 

В итоге порешалось все преобразованием в Integer.

Выводы отсюда - для ключей в SF нисколько нельзя использовать Decimal поле. Мало того что столько гемора, так еще и на UI ваш ID выглядит вот так 731,691 - согласитесь как то уже не похоже на ID. Ну и в коде Decimal использовать только для вычислений а не для ID, ключей и прочей шляпы где нужна точность. Понимаю создателей пакета, они по ходу не профильные разрабы SF и в других базах данных это нормальная практика использовать колонки в таблицах с типом Integer в виде числовых ключей. Но это не про SF.
если это недавно делалось то там сделали UUID класс уже встроенный и все отлично генерит
сталкивался с этой же проблемой с decimal, уже не помню конкретный случай но проблема была таже что не матчилось значение
если это недавно делалось то там сделали UUID класс уже встроенный и все отлично генерит
сталкивался с этой же проблемой с decimal, уже не помню конкретный случай но проблема была таже что не матчилось значение