Добрый день! Пытаюсь разобраться в структуре проекта. Есть длительный опыт с MSSQL, MySQL и в далеком прошлом ФоксПро. То есть о базах данных представление имеется. Была надежда, что с СФ быстренько разберусь. И тут началось... Открываю список объектов - их там чуть больше десятка всего. Открываю Схему - там просто в глазах рябит от количества объектов и связей. Почему не совпадает список объектов со схемой? И как тогда увидеть содержимое тех объектов, что есть на Схеме? При этом существует огромная Opportunity, с которой, судя по всему, идет основная работа. Насколько я понимаю, Object - это то, что в SQL является таблицей. А что есть Opportunity и почему она вынесена отдельно от объектов?
И по консоли вопрос. При попытке выбрать селектом все поля Опортунити появляется сообщение the soql fields function must have a limit of a most 200 Оппортунити, конечно, большая, но двухсот полей там точно нет. Или речь идет о длине запроса со всем перечнем полей? И как это обойти, чтобы увидеть таки все содержимое?
Добрый день!
Пытаюсь разобраться в структуре проекта. Есть длительный опыт с MSSQL, MySQL и в далеком прошлом ФоксПро. То есть о базах данных представление имеется. Была надежда, что с СФ быстренько разберусь. И тут началось...
Открываю список объектов - их там чуть больше десятка всего. Открываю Схему - там просто в глазах рябит от количества объектов и связей. Почему не совпадает список объектов со схемой? И как тогда увидеть содержимое тех объектов, что есть на Схеме?
При этом существует огромная Opportunity, с которой, судя по всему, идет основная работа.
Насколько я понимаю, Object - это то, что в SQL является таблицей. А что есть Opportunity и почему она вынесена отдельно от объектов?
И по консоли вопрос. При попытке выбрать селектом все поля Опортунити появляется сообщение
the soql fields function must have a limit of a most 200
Оппортунити, конечно, большая, но двухсот полей там точно нет. Или речь идет о длине запроса со всем перечнем полей? И как это обойти, чтобы увидеть таки все содержимое?
Спасибо
Opportunity не вынесен отдельно от объектов, это такой же объект как и любой другой, но с отдельными дополнительными плюшками. Да, объекты это типа таблицы в базе данных. Но таблицами никто давно уже не пользуется даже в других языках. Для этого существуют так называемые ORM (https://ru.wikipedia.org/wiki/ORM). Объекты в Salesforce это одна из разновидностей ORM, но язык запросов согласен очень похож на SQL (даже называется похоже SOQL). Так вот с объектами в SF не все так просто и эту тему надо очень хорошо разобрать. Это база!!!! https://trailhead.salesforce.com/content ... ts_intro
Opportunity не вынесен отдельно от объектов, это такой же объект как и любой другой, но с отдельными дополнительными плюшками. Да, объекты это типа таблицы в базе данных. Но таблицами никто давно уже не пользуется даже в других языках. Для этого существуют так называемые ORM (https://ru.wikipedia.org/wiki/ORM). Объекты в Salesforce это одна из разновидностей ORM, но язык запросов согласен очень похож на SQL (даже называется похоже SOQL). Так вот с объектами в SF не все так просто и эту тему надо очень хорошо разобрать. Это база!!!!
https://trailhead.salesforce.com/content/learn/modules/data_modeling/objects_intro
Прикольно, не доводилось использовать до этого, как-то оно прошло мимо меня (наверное как раз из-за этого ограничения не стал использовать) Я так понимаю что ты используешь
SELECT FIELDS(ALL) FROM Opportunity
Этот самый FIELDS накладывает ограничение на запрос. В нем должен быть LIMIT 200. Результат запроса не больше 200 записей. Посмотри тут везде в примерах этот лимит. https://developer.salesforce.com/docs/at ... elds.htm Поэтому если тебе надо выбрать больше 200 записей то надо явно указывать список полей
[quote="flider"]the soql fields function must have a limit of a most 200[/quote]
Прикольно, не доводилось использовать до этого, как-то оно прошло мимо меня (наверное как раз из-за этого ограничения не стал использовать)
Я так понимаю что ты используешь
[code]SELECT FIELDS(ALL) FROM Opportunity[/code]
Этот самый FIELDS накладывает ограничение на запрос. В нем должен быть LIMIT 200. Результат запроса не больше 200 записей. Посмотри тут везде в примерах этот лимит.
https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_fields.htm
Поэтому если тебе надо выбрать больше 200 записей то надо явно указывать список полей
[code]SELECT Id, Name, ... FROM Opportunity LIMIT 50000[/code]
Увы, количество записей не имеет значение. Запрос
SELECT [b]USER_ID__c[/b] FROM Opportunity WHERE CLASS__C=3
выдает 5 записей
SELECT [b]FIELDS(STANDARD)[/b] FROM Opportunity WHERE CLASS__C=3
выдает 2700 записей 20 стандартный полей, средняя длина названия поля меньше 10 символов
SELECT [b]FIELDS(ALL)[/b] FROM Opportunity WHERE CLASS__C=3
опять сообщает о лимите 200 120 кастомных полей + 20 стандартных, средняя длина поля больше 10 символов
Вероятно все же лимит наложен на итоговую длину самого запроса. Имхо FIELDS(ALL) - это краткое указание на запрашиваемые поля. То есть при обработке эта краткая запись будет развернута в полный список полей и если длина этого списка превышает 200, то упс.
[quote="Dmitry Shnyrev"][quote="flider"]the soql fields function must have a limit of a most 200[/quote]
Прикольно, не сталкивался до этого, приятно узнать что-то новое.
Капнул немного этот вопрос и вот что нарыл
https://www.sfdcstop.com/2021/01/soql-fields-is-now-generally-available.html
Я так понимаю что ты используешь
[code]SELECT [b]FIELDS(ALL)[/b] FROM Opportunity[/code]
Этот самый FIELDS накладывает ограничение на запрос. В нем должен быть LIMIT 200. Результат не больше 200 записей. Посмотри тут везде в примерах этот лимит.
https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_fields.htm
Поэтому если тебе надо выбрать больше 200 записей то надо явно указывать список полей
[code]SELECT Id, Name, ... FROM Opportunity LIMIT 50000[/code][/quote]
Увы, количество записей не имеет значение. Запрос
[code]SELECT [b]USER_ID__c[/b] FROM Opportunity WHERE CLASS__C=3[/code]
выдает 5 записей
[code]SELECT [b]FIELDS(STANDARD)[/b] FROM Opportunity WHERE CLASS__C=3[/code]
выдает 2700 записей
20 стандартный полей, средняя длина названия поля меньше 10 символов
[code]SELECT [b]FIELDS(ALL)[/b] FROM Opportunity WHERE CLASS__C=3[/code]
опять сообщает о лимите 200
120 кастомных полей + 20 стандартных, средняя длина поля больше 10 символов
Вероятно все же лимит наложен на итоговую длину самого запроса. Имхо FIELDS(ALL) - это краткое указание на запрашиваемые поля. То есть при обработке эта краткая запись будет развернута в полный список полей и если длина этого списка превышает 200, то упс.
Длина запроса тут не при чем. Добавь в те запросы где падает с ошибкой ... LIMIT 200 в конце и я уверен они перестанут падать.
Увы, количество записей не имеет значение. Запрос SELECT USER_ID__c FROM Opportunity WHERE CLASS__C=3 выдает 5 записей
SELECT FIELDS(STANDARD) FROM Opportunity WHERE CLASS__C=3 выдает 2700 записей
А это вообще звучит как бред. WHERE одинаковый в обоих запросах, как тогда разное количество записей возвращается?
Я больше верю что и там и там должно быть 2700. И это как раз про наш лимит в 200. Поставь в конце запроса LIMIT 200 и тебе вернется 200 записей без ошибки
Длина запроса тут не при чем.
Добавь в те запросы где падает с ошибкой ... LIMIT 200 в конце и я уверен они перестанут падать.
[quote="flider"]Увы, количество записей не имеет значение. Запрос
SELECT USER_ID__c FROM Opportunity WHERE CLASS__C=3
выдает 5 записей
SELECT FIELDS(STANDARD) FROM Opportunity WHERE CLASS__C=3
выдает 2700 записей[/quote]
А это вообще звучит как бред. WHERE одинаковый в обоих запросах, как тогда разное количество записей возвращается?
Я больше верю что и там и там должно быть 2700. И это как раз про наш лимит в 200. Поставь в конце запроса LIMIT 200 и тебе вернется 200 записей без ошибки
Длина запроса, длина названия полей никогда не были проблемой. Я могу выбрать все поля вручную составить из них километровый запрос и он 100500% отработает
Длина запроса, длина названия полей никогда не были проблемой. Я могу выбрать все поля вручную составить из них километровый запрос и он 100500% отработает
Есть такая штука классная https://workbench.developerforce.com/login.php Там можно подрубиться к оргу и делать разные интересные плюшки, в том числе и запрос сгенерировать со всеми полями. Попробуй там запрос на Opportunity со всеми полями - уверен что там никаких ошибок не будет и все отработает. Точно также и в SF должно работать
Есть такая штука классная
https://workbench.developerforce.com/login.php
Там можно подрубиться к оргу и делать разные интересные плюшки, в том числе и запрос сгенерировать со всеми полями.
Попробуй там запрос на Opportunity со всеми полями - уверен что там никаких ошибок не будет и все отработает. Точно также и в SF должно работать
Длина запроса тут не при чем. Добавь в те запросы где падает с ошибкой ... LIMIT 200 в конце и я уверен они перестанут падать.
А это вообще звучит как бред. WHERE одинаковый в обоих запросах, как тогда разное количество записей возвращается?
Я больше верю что и там и там должно быть 2700. И это как раз про наш лимит в 200. Поставь в конце запроса LIMIT 200 и тебе вернется 200 записей без ошибки
Прошу прощения, неверно написано. Смысл в том, что при перечислении в селекте конкретных полей, выдается и 5 записей, и 700 и 2700. Стоит в том же самом запросе поменять конкретные поля на ВСЕ поля, так сразу лимит 200. Если добавить в запрос limit 200, то, действительно, ошибки про лимит не выскакивает, но и вместо данных красные черточки в каждой ячейке с данными - 2 строки или 200 или 700.
Есть такая штука классная https://workbench.developerforce.com/login.php Там можно подрубиться к оргу и делать разные интересные плюшки, в том числе и запрос сгенерировать со всеми полями.
О, спасибо, поюзаю.
И все же, почему может быть разное количество объектов в списке и в схеме?
[quote="Dmitry Shnyrev"]Длина запроса тут не при чем.
Добавь в те запросы где падает с ошибкой ... LIMIT 200 в конце и я уверен они перестанут падать.
А это вообще звучит как бред. WHERE одинаковый в обоих запросах, как тогда разное количество записей возвращается?
Я больше верю что и там и там должно быть 2700. И это как раз про наш лимит в 200. Поставь в конце запроса LIMIT 200 и тебе вернется 200 записей без ошибки
[/quote]
Прошу прощения, неверно написано. Смысл в том, что при перечислении в селекте конкретных полей, выдается и 5 записей, и 700 и 2700. Стоит в том же самом запросе поменять конкретные поля на ВСЕ поля, так сразу лимит 200.
Если добавить в запрос limit 200, то, действительно, ошибки про лимит не выскакивает, но и вместо данных красные черточки в каждой ячейке с данными - 2 строки или 200 или 700.
[quote="Dmitry Shnyrev"]Есть такая штука классная
https://workbench.developerforce.com/login.php
Там можно подрубиться к оргу и делать разные интересные плюшки, в том числе и запрос сгенерировать со всеми полями.[/quote]
О, спасибо, поюзаю.
И все же, почему может быть разное количество объектов в списке и в схеме?
И все же, почему может быть разное количество объектов в списке и в схеме?
Не объектов, а записей. Объекты = таблицы Записи = записи
Schema Builder это представление всех объектов, которые ты выбрал, на странице, с их связями
В SF есть очень много объектов, про которые вообще можно не знать, забыть, нельзя использовать, нельзя делать селекты, нельзя создавать, редактировать и тд.
И все же, почему может быть разное количество объектов в списке и в схеме?
Вот этот вопрос он про записи или про объекты?
FIELDS(ALL) вообще бесполезная вещь, она может быть полезна только ленивым. Лимит в 200 записей, для того чтобы ленивые люди перестали быть ленивыми и перестали нагружать сервера SF запросами с выборкой Rich/Long text are полей, в которые можно сохранить википедию.
Делать SOQL(он же SQL запрос) нужно вдумчиво, понимая какие данные нужны, а какие нет. А также нужно вдумчиво строить WHERE чтобы отсекать ненужные записи.
[quote="flider"]И все же, почему может быть разное количество объектов в списке и в схеме?[/quote]
Не объектов, а записей.
Объекты = таблицы
Записи = записи
Schema Builder это представление всех объектов, которые ты выбрал, на странице, с их связями
В SF есть очень много объектов, про которые вообще можно не знать, забыть, нельзя использовать, нельзя делать селекты, нельзя создавать, редактировать и тд.
[quote="flider"]И все же, почему может быть разное количество объектов в списке и в схеме?[/quote]
Вот этот вопрос он про записи или про объекты?
FIELDS(ALL) вообще бесполезная вещь, она может быть полезна только ленивым. Лимит в 200 записей, для того чтобы ленивые люди перестали быть ленивыми и перестали нагружать сервера SF запросами с выборкой Rich/Long text are полей, в которые можно сохранить википедию.
Делать SOQL(он же SQL запрос) нужно вдумчиво, понимая какие данные нужны, а какие нет. А также нужно вдумчиво строить WHERE чтобы отсекать ненужные записи.
Если добавить в запрос limit 200, то, действительно, ошибки про лимит не выскакивает, но и вместо данных красные черточки в каждой ячейке с данными - 2 строки или 200 или 700.
Ну тут я не помогу. Макс выше правильно сказал - лучше не используй FIELDS(ALL) это только запутывает учитывая отсутствие опыта. Делай более детальные запросы с нужными полями и вменяемым WHERE и будет счастье.
[quote="flider"]Если добавить в запрос limit 200, то, действительно, ошибки про лимит не выскакивает, но и вместо данных красные черточки в каждой ячейке с данными - 2 строки или 200 или 700.[/quote]
Ну тут я не помогу. Макс выше правильно сказал - лучше не используй FIELDS(ALL) это только запутывает учитывая отсутствие опыта. Делай более детальные запросы с нужными полями и вменяемым WHERE и будет счастье.
И все же, почему может быть разное количество объектов в списке и в схеме?
Не объектов, а записей. Объекты = таблицы Записи = записи
Именно объектов в данном случае - в этом вопросе имелся в виду список - Create-Objects. Там несколько стандартных объектов-таблиц и 15 кастомных. А в схеме масса объектов.
Schema Builder это представление всех объектов, которые ты выбрал, на странице, с их связями
В SF есть очень много объектов, про которые вообще можно не знать, забыть, нельзя использовать, нельзя делать селекты, нельзя создавать, редактировать и тд.
Вооот, спасибо за ценную информацию. Эта масса объектов на схеме - всякие служебные таблицы, которые отсутствуют в списке объектов. Удалось разобраться.
FIELDS(ALL) вообще бесполезная вещь, она может быть полезна только ленивым. Лимит в 200 записей, для того чтобы ленивые люди перестали быть ленивыми и перестали нагружать сервера SF запросами с выборкой Rich/Long text are полей, в которые можно сохранить википедию.
Делать SOQL(он же SQL запрос) нужно вдумчиво, понимая какие данные нужны, а какие нет. А также нужно вдумчиво строить WHERE чтобы отсекать ненужные записи.
Не, тут не в лени дело. Просто мне надо добавить в Оппортунити некий массив данных для нового проекта. И для этого пытаюсь понять какие данные в какие поля добавлять, поскольку на юзерской вкладке, где частично эта Оппортунити используется, названия полей частично не совпадают с названием полей в самой Оппортунити. Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет. Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.
[quote="Maxim Elets"][quote="flider"]И все же, почему может быть разное количество объектов в списке и в схеме?[/quote]
Не объектов, а записей.
Объекты = таблицы
Записи = записи[/quote]
Именно объектов в данном случае - в этом вопросе имелся в виду список - Create-Objects. Там несколько стандартных объектов-таблиц и 15 кастомных. А в схеме масса объектов.
[quote="Maxim Elets"]Schema Builder это представление всех объектов, которые ты выбрал, на странице, с их связями
В SF есть очень много объектов, про которые вообще можно не знать, забыть, нельзя использовать, нельзя делать селекты, нельзя создавать, редактировать и тд.[/quote]
Вооот, спасибо за ценную информацию. Эта масса объектов на схеме - всякие служебные таблицы, которые отсутствуют в списке объектов. Удалось разобраться.
[quote="Maxim Elets"]
FIELDS(ALL) вообще бесполезная вещь, она может быть полезна только ленивым. Лимит в 200 записей, для того чтобы ленивые люди перестали быть ленивыми и перестали нагружать сервера SF запросами с выборкой Rich/Long text are полей, в которые можно сохранить википедию.
Делать SOQL(он же SQL запрос) нужно вдумчиво, понимая какие данные нужны, а какие нет. А также нужно вдумчиво строить WHERE чтобы отсекать ненужные записи.
[/quote]
Не, тут не в лени дело. Просто мне надо добавить в Оппортунити некий массив данных для нового проекта. И для этого пытаюсь понять какие данные в какие поля добавлять, поскольку на юзерской вкладке, где частично эта Оппортунити используется, названия полей частично не совпадают с названием полей в самой Оппортунити. Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет. Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.
Не, тут не в лени дело. Просто мне надо добавить в Оппортунити некий массив данных для нового проекта. И для этого пытаюсь понять какие данные в какие поля добавлять, поскольку на юзерской вкладке, где частично эта Оппортунити используется, названия полей частично не совпадают с названием полей в самой Оппортунити. Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет. Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.
Вот тут надо смотреть конечно Но такого что поля нет, а на странице поле есть, быть конечно не может
[quote="flider"]Не, тут не в лени дело. Просто мне надо добавить в Оппортунити некий массив данных для нового проекта. И для этого пытаюсь понять какие данные в какие поля добавлять, поскольку на юзерской вкладке, где частично эта Оппортунити используется, названия полей частично не совпадают с названием полей в самой Оппортунити. Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет. Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.[/quote]
Вот тут надо смотреть конечно
Но такого что поля нет, а на странице поле есть, быть конечно не может
Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.
Проверь Field Label - то что видно на page layout Field API Name - поле которое пишется в SOQL
обычно они совпадают или почти одинаковые. может у тебя они разные и поэтому тяжело найти.
[quote="flider"]Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.[/quote]
Проверь Field Label - то что видно на page layout
Field API Name - поле которое пишется в SOQL
обычно они совпадают или почти одинаковые.
может у тебя они разные и поэтому тяжело найти.
Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет.
О! Это больная тема. Eric правильно заметил! У каждого поля есть API Name - то что используется в SOQL запросах и в коде и Label - то что видно в интерфейса. При создании они выглядят похоже, но потом клиенту приходит в голову замечательная идея переименовать поле. API Name поменять сложно если оно уже используется в коде, а Label просто. И получается что к примеру ты видешь на странице поле DateInactivate а в базе оно будет называться Date_When_I_Was_Born__c.
[quote="flider"]Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет.[/quote]
О! Это больная тема.
Eric правильно заметил!
У каждого поля есть API Name - то что используется в SOQL запросах и в коде и Label - то что видно в интерфейса. При создании они выглядят похоже, но потом клиенту приходит в голову замечательная идея переименовать поле. API Name поменять сложно если оно уже используется в коде, а Label просто. И получается что к примеру ты видешь на странице поле DateInactivate а в базе оно будет называться Date_When_I_Was_Born__c.
обычно они совпадают или почти одинаковые. может у тебя они разные и поэтому тяжело найти.
Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет.
О! Это больная тема. Eric правильно заметил! У каждого поля есть API Name - то что используется в SOQL запросах и в коде и Label - то что видно в интерфейса. При создании они выглядят похоже, но потом клиенту приходит в голову замечательная идея переименовать поле. API Name поменять сложно если оно уже используется в коде, а Label просто. И получается что к примеру ты видешь на странице поле DateInactivate а в базе оно будет называться Date_When_I_Was_Born__c.
Вооот, это походу оно и есть. И была надежда через fields (all) произвести сопоставление что где как называется. Спасибо, буду ковырять дальше.
Там навернуто местами весело. Уже то, что, как выяснилось, в Оппортунити уникальный номер каждой строки имеет название поля User_ID с какого-то перепугу, а номер юзера - UserID... Некоторое время заняло понять, почему по select User_ID__c, Username__c вываливаются одинаковые имена с разными АйДи, а у части имен вообще нету АйДи...
[quote="Eric"]обычно они совпадают или почти одинаковые.
может у тебя они разные и поэтому тяжело найти.[/quote]
[quote="Dmitry Shnyrev"][quote="flider"]Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет.[/quote]
О! Это больная тема.
Eric правильно заметил!
У каждого поля есть API Name - то что используется в SOQL запросах и в коде и Label - то что видно в интерфейса. При создании они выглядят похоже, но потом клиенту приходит в голову замечательная идея переименовать поле. API Name поменять сложно если оно уже используется в коде, а Label просто. И получается что к примеру ты видешь на странице поле DateInactivate а в базе оно будет называться Date_When_I_Was_Born__c.
[/quote]
Вооот, это походу оно и есть. И была надежда через fields (all) произвести сопоставление что где как называется. Спасибо, буду ковырять дальше.
Там навернуто местами весело. Уже то, что, как выяснилось, в Оппортунити уникальный номер каждой строки имеет название поля User_ID с какого-то перепугу, а номер юзера - UserID... Некоторое время заняло понять, почему по select User_ID__c, Username__c вываливаются одинаковые имена с разными АйДи, а у части имен вообще нету АйДи...