Привет.
Сегодня столкнулся с крайне непонятной проблемой и уже полдня ломаю голову
Есть простой Queueable класс который запускается асинхронно и делает один запрос из базы чтобы отослать данные в сторонний сервис.
Так вот почему-то одно поле (обычный picklist) упорно не хочет возвращать свое значение в запросе. Вроде поле обычное, все и для всех права на него открыты, когда я делаю запрос синхронно - значение вижу, асинхронный контекст выполняется тоже от моего имени. НО МЛЯ значение пустое. Я даже сделал поле Formula и выводу значение через него - синхронно вижу, асинхронно НЕТ!
ЧТО ЗА БРЕД?
Нет все еще хуже!!!
Поля не видно даже синхронно. Продублировал запрос перед асинхронным вызовом.
Тоже пусто. Код этот вызывается из триггера и проверяю я ручным апдейтом записи через стандарт лайаут.
Т.е. код лежит класса without sharing и вызывается из триггера - нет значения.
Воожу запрос через Developer Console - работает - вижу значение.
ЧТО МЛЯ ЗА БРЕД ТАКОЙ?
Все! У меня просто мозг отказывается понимать что либо!
- создал еще одно поле Picklist -
- расшарил все возможные пермишены.
- выкинул поле на Layout
- редактирую, сохраняю, перегружаю страницу - значение поля на месте.
- добавил поле в Formula Field - вижу поле и значения в нем
- Запрос - и НИХЕРА! ПУСТО. Формула поле - там где должны быть значения полей - пусто.
Может Set Permission какой ?
Пока не понимаю как PermossionSet может повлиять, но посмотрю.
Еще интереснее наблюдение:
Через Developer Console запускаю - метод из класса который делает запрос - нет значение
Делаю тот же самый запрос просто - есть значения.
Продолжаю ломать голову.
Еще интереснее наблюдение:
Через Developer Console запускаю - метод из класса который делает запрос - нет значение
Делаю тот же самый запрос просто - есть значения.
Продолжаю ломать голову.
у меня было что то похожие когда пытался получить getContext cтраницы в Dev Console.
Интересно в женской бане, а если не сложно - можно пример кода?
Товарищи! Я разобрался.
Это очень редкое стечение обстоятельств:
гениальность предыдущего разраба и моя невнимательность.
В двух словах - задача была простая -
достать Контакты и связи между ними, заданные в кастомном junction object.
Связь односторонняя так что по смыслу понятно что должен быть один объект связи.
А не тут-то было - где-то в дебрях кода предыдущий разраб сотворил мега триггер который делает дублирующий junction object но меняет местами id контактов. Ну и конечно чтобы не смущать клиента вторая связь была скрыта со всех лайоутов, таким образом подумать о ее существовании было нельзя.
Теперь раковое стечение обстоятельств и моя невнимательность. Я перепутал поле по которому надо искать подчиненных контактов и получал как раз связи те что скрыты (не те что видны пользователю). Ну в тестах сравнил количество - совпало и ок. Содержимое полей не смотрел.
В итоге видим на странице 4 записи связей с заполненными доп полями - и в отправляемом запросе видим 4 записи с незаполненными полями (! причем некоторыми - остальные предательски заполнялись по умолчанию и были как раз похожи на то что имел клиент в оригинальных объектах).
Да, все бы было проще если бы я допустил мысль что junction objects может быть больше чем я вижу и хотя бы я сравнил ID в запросе с тем что я вижу на странице - вся проблема в количестве которое предательски било везде - и по тестам и визуально.
ок, ты хотел обратиться к одному junction object (или через него), но обращался на самом деле к другому (или через другой). А что АПИ имена одинаковы?
Немного не так.
Есть такая связь:
Child Contact < Junction_Object__c(Child__c(Contact MD), Parent__c(Contact MD)) > ParentContact
По логике чтобы связать 2 контакта достаточно создать 1 JO и заполнить 2 MD.
В моем случае создавалось 2 JO которые различались тем что оба MD были поменяны местами:
1. jo1(Child__c=Contact1, Parent__c=Contact2)
2. jo2(Child__c=Contact2, Parent__c=Contact1)
Конечно API Names у jo1 и jo2 одинаковые потому что это 2 записи одного Junction_Object__c
Как-то так :)
Кстати давно заметил неразбериху с названием Объектов и Записей в SF.
Особенно это касается общения с людьми из других областей особенно близких к ОРМ.
Знакомые обычно про Объект думают про запись. Т.е. например "селектнул лист объектов". А Объект по ихнему это Модель.
Да чего далеко ходить, даже SFники тоже как попало используют понятия Объекты(Standard, Custom) и Записи(Records).
ну это особый случай.
во первых, у тебя не два jo, а две "конфликтующие" записи в пределах одного jo.
но такая проблема возможна только если это jo на тот же самый объект!!!!! (т.е. какой-то объект имеет jo на самого себя)
я такого еще не встречал...
Проблемы возможны всякие 
Все зависит от криворукости программиста 
Потому что это не проблема кода или проблема CRM - это проблема бизнес логики. Возможно просто изначально делалось одно, а потом 30 раз переделывалось (и я собственно продолжаю переделывать) поэтому и остались всякие вот такие артефакты. В мою компетенцию по задаче не входит анализ и улучшение существующего функционала - мне платят за доп функционал. Я отписал заказчику - но не уверен что тот понял - внешне та все работает - а пока работает не трогая (золотые слова)!!!
я не говорю, что там проблемы с ДБ архитектурой, вероятно все в порядке.
просто сама ситуация, когда требуется "self-reference" связь типа Many-to-Many, что приводит к созданию jo завязанного на один и тот же объект, интересно...
