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

Objects, Opportunity, Schema Builders etc.

Добрый день!
Пытаюсь разобраться в структуре проекта. Есть длительный опыт с 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
flider
the soql fields function must have a limit of a most 200
Прикольно, не доводилось использовать до этого, как-то оно прошло мимо меня (наверное как раз из-за этого ограничения не стал использовать)
Я так понимаю что ты используешь
  1. SELECT FIELDS(ALL) FROM Opportunity
Этот самый FIELDS накладывает ограничение на запрос. В нем должен быть LIMIT 200. Результат запроса не больше 200 записей. Посмотри тут везде в примерах этот лимит.
https://developer.salesforce.com/docs/at ... elds.htm
Поэтому если тебе надо выбрать больше 200 записей то надо явно указывать список полей
  1. SELECT Id, Name, ... FROM Opportunity LIMIT 50000
[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]
Dmitry Shnyrev
flider
the soql fields function must have a limit of a most 200
Прикольно, не сталкивался до этого, приятно узнать что-то новое.
Капнул немного этот вопрос и вот что нарыл
https://www.sfdcstop.com/2021/01/soql-fields-is-now-generally-available.html
Я так понимаю что ты используешь
  1. SELECT [b]FIELDS(ALL)[/b] FROM Opportunity
Этот самый 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 записей то надо явно указывать список полей
  1. SELECT Id, Name, ... FROM Opportunity LIMIT 50000

Увы, количество записей не имеет значение. Запрос
  1. SELECT [b]USER_ID__c[/b] FROM Opportunity WHERE CLASS__C=3
выдает 5 записей

  1. SELECT [b]FIELDS(STANDARD)[/b] FROM Opportunity WHERE CLASS__C=3
выдает 2700 записей
20 стандартный полей, средняя длина названия поля меньше 10 символов

  1. 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 в конце и я уверен они перестанут падать.

flider
Увы, количество записей не имеет значение. Запрос
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 должно работать

Dmitry Shnyrev
Длина запроса тут не при чем.
Добавь в те запросы где падает с ошибкой ... LIMIT 200 в конце и я уверен они перестанут падать.

А это вообще звучит как бред. WHERE одинаковый в обоих запросах, как тогда разное количество записей возвращается?

Я больше верю что и там и там должно быть 2700. И это как раз про наш лимит в 200. Поставь в конце запроса LIMIT 200 и тебе вернется 200 записей без ошибки

Прошу прощения, неверно написано. Смысл в том, что при перечислении в селекте конкретных полей, выдается и 5 записей, и 700 и 2700. Стоит в том же самом запросе поменять конкретные поля на ВСЕ поля, так сразу лимит 200.
Если добавить в запрос limit 200, то, действительно, ошибки про лимит не выскакивает, но и вместо данных красные черточки в каждой ячейке с данными - 2 строки или 200 или 700.

Dmitry Shnyrev
Есть такая штука классная
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]
О, спасибо, поюзаю.


И все же, почему может быть разное количество объектов в списке и в схеме?
flider
И все же, почему может быть разное количество объектов в списке и в схеме?
Не объектов, а записей.
Объекты = таблицы
Записи = записи

Schema Builder это представление всех объектов, которые ты выбрал, на странице, с их связями

В SF есть очень много объектов, про которые вообще можно не знать, забыть, нельзя использовать, нельзя делать селекты, нельзя создавать, редактировать и тд.

flider
И все же, почему может быть разное количество объектов в списке и в схеме?
Вот этот вопрос он про записи или про объекты?

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 чтобы отсекать ненужные записи.
flider
Если добавить в запрос limit 200, то, действительно, ошибки про лимит не выскакивает, но и вместо данных красные черточки в каждой ячейке с данными - 2 строки или 200 или 700.
Ну тут я не помогу. Макс выше правильно сказал - лучше не используй FIELDS(ALL) это только запутывает учитывая отсутствие опыта. Делай более детальные запросы с нужными полями и вменяемым WHERE и будет счастье.
[quote="flider"]Если добавить в запрос limit 200, то, действительно, ошибки про лимит не выскакивает, но и вместо данных красные черточки в каждой ячейке с данными - 2 строки или 200 или 700.[/quote]
Ну тут я не помогу. Макс выше правильно сказал - лучше не используй FIELDS(ALL) это только запутывает учитывая отсутствие опыта. Делай более детальные запросы с нужными полями и вменяемым WHERE и будет счастье. 
Maxim Elets
flider
И все же, почему может быть разное количество объектов в списке и в схеме?
Не объектов, а записей.
Объекты = таблицы
Записи = записи
Именно объектов в данном случае - в этом вопросе имелся в виду список - Create-Objects. Там несколько стандартных объектов-таблиц и 15 кастомных. А в схеме масса объектов.

Maxim Elets
Schema Builder это представление всех объектов, которые ты выбрал, на странице, с их связями

В SF есть очень много объектов, про которые вообще можно не знать, забыть, нельзя использовать, нельзя делать селекты, нельзя создавать, редактировать и тд.
Вооот, спасибо за ценную информацию. Эта масса объектов на схеме - всякие служебные таблицы, которые отсутствуют в списке объектов. Удалось разобраться.


Maxim Elets
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, а в Оппортунити такого поля нет. Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.
flider
Не, тут не в лени дело. Просто мне надо добавить в Оппортунити некий массив данных для нового проекта. И для этого пытаюсь понять какие данные в какие поля добавлять, поскольку на юзерской вкладке, где частично эта Оппортунити используется, названия полей частично не совпадают с названием полей в самой Оппортунити. Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет. Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.

Вот тут надо смотреть конечно
Но такого что поля нет, а на странице поле есть, быть конечно не может
[quote="flider"]Не, тут не в лени дело. Просто мне надо добавить в Оппортунити некий массив данных для нового проекта. И для этого пытаюсь понять какие данные в какие поля добавлять, поскольку на юзерской вкладке, где частично эта Оппортунити используется, названия полей частично не совпадают с названием полей в самой Оппортунити. Скажем на вкладке есть поле DateInactivate, а в Оппортунити такого поля нет. Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.[/quote]

Вот тут надо смотреть конечно
Но такого что поля нет, а на странице поле есть, быть конечно не может
flider
Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.

Проверь Field Label - то что видно на page layout
Field API Name - поле которое пишется в SOQL

обычно они совпадают или почти одинаковые.
может у тебя они разные и поэтому тяжело найти.
[quote="flider"]Поэтому была мысль хотя бы посмотреть какие данные в каком поле записаны.[/quote]

Проверь Field Label - то что видно на page layout
Field API Name - поле которое пишется в SOQL

обычно они совпадают или почти одинаковые.
может у тебя они разные и поэтому тяжело найти.
flider
Скажем на вкладке есть поле 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. 
Eric
обычно они совпадают или почти одинаковые.
может у тебя они разные и поэтому тяжело найти.

Dmitry Shnyrev
flider
Скажем на вкладке есть поле 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 вываливаются одинаковые имена с разными АйДи, а у части имен вообще нету АйДи...