Самые сложные SOQL запросы которые вы встречали, писали или видели. И "среднестатистический запрос"
Главное чтобы они были синтаксически и семантически правильными
Хочу кое что протестировать - буду рад если поделитесь.
Так же если не сложно можете привести пример наиболее частых запросов?
Так сказать "Сферический запрос в вакууме". Что-то в духе : 60-80% случаев если вы захотите писать запрос - он будет похож на этот наш "среднестатистический запрос"
Да без JOIN запросов в Salesforce собственно все запросы становятся легкими. Основной упор ложится на WHERE секцию, ну а тут что может быть сложного? Перечисляй критерии и просто не ошибись. Сколько работаю никогда не сталкивался со сложными запросами. в 99% случаев запросы состоят 2-3 критериев в WHERE + секции ORDER BY. Если сложного могу выделить работу с SOSL, но и то сложно потому что приходится редко работать и каждый раз приходится лезть в документацию чтобы вспомнить.
Он не сложный, но дебильный. Наверное я его спъяну написал.
Set<Id> valids = new Set<Id>(); ... List<customObj2__c> list01 = [ SELECT Id, cutomObj1__c FROM customObj2__c WHERE customObj1__r.Id IN :valids ORDER BY Timestamp__c ASC ];
Не, точно не я - я переменную valids не назову. Так вот эта штука в тесте у меня на почти голом дэв орге выдает:
А почему вы используете именно customObj1__r.Id, а не CustomObj1__c? Если данный запрос у вас не в цикле, то рискну предположить что именно в этом скрытом "join'е" вся загвоздка.
Я не уверен, но вроди туда входять рекорди с isDeleted = true, возможно в корзине куча рекордов лежит.
Пустой орг. Предположу, что проблема может быть в
1. The filter value includes null (for instance binding with a list that contains null)
А почему вы используете именно customObj1__r.Id, а не CustomObj1__c? Если данный запрос у вас не в цикле, то рискну предположить что именно в этом скрытом "join'е" вся загвоздка.
Именно в этом. И только на одном орге. На другом - все в порядке. Орги идентичные. Почти. Один без данных. Но код и объекты один в один. После исправления на __с оно-то тесты прошли. Это было до меня. Так два года висело. Пока именно сегодня не стрельнуло. Дывына.
[SELECT COUNT_DISTINCT(Master__c) FROM Childs__c WHERE Master__r.MasterParent__c = :rec.id]
если переписать так:
[SELECT COUNT() FROM Childs__c WHERE Master__r.MasterParent__c = :rec.id]
то просто вернет кол-во "правильных" дочерних записей и не дает ответа на задачу "получить кол-во только тех записей у которых есть дочерние записи"
а как написано в оригинале - возвращает List<AggregateResult>, я не проверял, можно ли его использовать для решения данной задачи, кроме того, чем такое решение проще моего, более прямолинейного.
Если вам надо получить только кол-со, то +1 за COUNT_DISTINCT, можете подредактировать его добавив
COUNT_DISTINCT(Master__c) quantity тогда значение сможете вытаскивать чуть более красиво: quantity = (Integer) argList.get(0).get('quantity'); Если надо сразу получить записи то:
SELECT Name FROM Master__c WHERE Id IN (SELECT Master__c from Child__c WHERE Master__r.MasterParent__c = :rec.Id)
всем спасибо.
порой сидишь, придумываешь отличную логику, чтобы решить задачу. Потом понимаешь, что это все можно сделать просто правильно построив SOQL...