Всім привіт!
У цій статті ми розглянемо Relationship Fields та Polymorphic Fields
ЩО ТАКЕ ПОЛІМОРФНІ ПОЛЯ В SALESFORCE?
Спочатку давайте погуглимо, що означає поліморфний.
Ось що я знайшла:
Поліморфний /poli mɔ fik/ (прикметник) - зустрічаються в кількох різних формах, зокрема щодо видових або генетичних варіацій.
Приклад - “поліморфні види риб”.
ПРОГРАМУВАННЯ
(особливості мови програмування), що дозволяє підпрограмам використовувати змінні різних типів у різний час.
Приклад - “корисні поліморфні функції”
За цим значенням, наданим Google, ми можемо приблизно перекласти нашу сьогоднішню тему як: РІЗНОВИД ПОЛЯ, ЩО ВКАЗУЄ НА ОДИН АБО КІЛЬКА ОБ’ЄКТІВ.
Збентежені?
Спростімо цю концепцію з точки зору програмування:
Ви маєте 3 екземпляри двох різних об’єктів
A(a) : екземпляр A класу “a”.
A1(a) : екземпляр A1 класу “a”.
B(b) : екземпляр B класу ‘b’.
Якщо ви спробуєте призначити A1 до A, його буде легко присвоєно, оскільки вони є екземплярами одного об’єкта.
Якщо ви спробуєте призначити A разом із B, наш компілятор видасть повідомлення про помилку «Неможливо призначити об’єкту A(a) значення B(b)».
Але тут, якщо у вас є щось на кшталт загального екземпляра (загальна змінна, яка приймає всі типи даних) в екземплярі A, який може зберігати екземпляр самого себе та інших об’єктів.
Це заощадить нам багато накладних витрат, пов’язаних із кількома полями для зберігання різних даних для різних об’єктів.
ЧИМ ЦЕ КОРИСНО?
Поліморфні поля дають Salesforce перевагу над використанням одного поля для багаторазового використання, відстежуючи спеціальні метадані, пов’язані з цим полем, щоб контролювати його поліморфну природу, дозволяючи екосистемі мати поле, яке може діяти відповідно до використання.
Поля для ПРИКЛАДУ:
Поле OwnerId ми бачимо у записах усіх об’єктів.
Поле Who на таких об’єктах як Task, Event тощо.
ХОЧЕТЕ ЗНАТИ БІЛЬШЕ?
Але поліморфізм цих полів контролюється використанням його метаданих/властивостей.
Ви не можете створювати custom поліморфні lookups в Salesforce. Вам потрібно буде створити два окремих поля lookup: одне для Account та інше для Opportunity. Тоді ви можете, за бажанням, використовувати formula fields, щоб отримати дані з будь-якого заповненого lookup. Однак ви не зможете досягти такого ж вигляду та відчуття, як рідні Related To або Name polymorphic lookups.
ЯК ЦЕ КОНТРОЛЮЄТЬСЯ ЗА МЕТАДАНИМИ / ВЛАСТИВОСТЯМИ?
Поля релейшеншип містять три властивості, які визначають характер дії цього поля в певному середовищі.
Розглянемо приклад поля OwnerId:
Поле OwnerId об’єкта Account має такі властивості:
relationshipName = Owner
namePointing = false
referenceTo = User
Це говорить про те, що це поле релейшеншип, а не POLYMORPHIC.
“relationshipName” діє як псевдополе для отримання інформації про пов’язаний об’єкт, тип якого вказано в полі “referenceTo”.
Але тепер уважно подивіться на значення властивостей. Поле OwnerId об’єкта Event має такі властивості:
relationshipName = Owner
namePointing = true
referenceTo = Calendar, User
Це означає, що це поліморфне поле. Owner може бути Calendar або User.
ВИ ЦЕ БАЧИЛИ ?
Так, стан властивості «namePointing» визначив стан поля (Pелейшеншип/Поліморфний)
Крім того, поле «referenceTo» пояснює поліморфну природу поля (тип значень об’єкта, які воно може містити для цього екземпляра, це Calendar і User).
Тепер, гадаю, трохи зрозуміліше, чим і як досягається поліморфізм.
ЯК ДІЗНАТИСЯ, ЧИ ПОЛЕ Є ПОЛЕМ РЕЛЕЙШИНШИП, ЧИ ПОЛІМОРФІЗМУ?
Щоб визначити тип поля, викличте “describeSObjects()” для об’єкта та перевірте властивості поля.
Якщо RelationName не null, це поле є полем релейшеншип.
Якщо, крім того, namePointing має значення true, то поле є поліморфним.
ВИКОРИСТОВУЙ ЦЕ:
List <Schema.DescribeSObjectResult> descResult = Schema.describeSObjects( new List <String> {'Account', 'Event'});
system.debug('DETAILS = ' + descResult);
Зупинимося на використанні,
Я наведу декілька прикладів, які зроблять речі набагато зрозумілішими.
SELECT Id, Owner.Name
FROM Event
WHERE Owner.Type = 'User'
Наведений вище SOQL вибирає всі записи Event із Owner.Type як ‘User’.
Таким чином, це показано згідно з попереднім поясненням. Властивість «referenceTo» поля релейшеншип можна отримати за допомогою ключового слова «Type».
SELECT Id, Who.Id, Who.Type FROM Task
Цей SOQL використовує поле релейшеншип Who в об’єкті Task, яке може відноситись як до Contact, так і до Account.
SELECT Id, Who.FirstName, Who.LastName
FROM Task
WHERE Owner.FirstName LIKE 'SHR%'
Цей приклад схожий на попередній, лише в ньому іще доданий оператор LIKE завдяки якому ми можемо зробити вибірку, у даному випадку, за Owner.FirstName
Використання TYPEOF
SOQL підтримує поліморфні зв’язки за допомогою TYPEOF в SELECT.
Використовуйте TYPEOF в SELECT, щоб контролювати, які поля запитувати для кожного типу об’єкта в поліморфному зв’язку. Наступний SELECT оператор повертає інший набір полів залежно від типу об’єкта, пов’язаного з What поліморфного релейшиншин поля в Event.
SELECT
TYPEOF What
WHEN Account THEN Phone, NumberOfEmployees
WHEN Opportunity THEN Amount, CloseDate
ELSE Name, Email
END
FROM Event
Під час виконання це SELECT оператор перевіряє тип об’єкта, на який посилається What поле в Event. Якщо тип об’єкта – Account, повертаються поля Phone і NumberOfEmployee, які вказані в цьому Account. Якщо тип об’єкта – Opportunity, повертаються поля Amount і CloseDate. Якщо тип об’єкта є будь-яким іншим типом, то повертаються поля Name та Email. Зауважте, що якщо ELSE речення не надано, і тип об’єкта не є Account або Opportunity — тоді повертається null для цього Event.
Зверніть увагу на наступні міркування щодо TYPEOF:
- TYPEOF не можна використовувати з релейшеншип полем, чий namePointing атрибут false.
- TYPEOF не можна використовувати з релейшеншип полем, чий relationshipName атрибут false.
- TYPEOF дозволено використовувати лише в SELECT пунктi запиту. Ви можете відфільтрувати тип об’єкта поліморфного зв’язку за допомогою TYPE кваліфікатор у WHERE.
- TYPEOF не допускається в запитах, які не повертають об’єкти, наприклад COUNT() і aggregate запити.
- TYPEOF не можна використовувати в запитах SOQL, які є основою PushTopics Streaming API.
- TYPEOF не можна використовувати в SOQL, що використовується в Bulk API.
- TYPEOF вирази не можуть бути вкладеними. Наприклад, не можна використовувати TYPEOF всередині WHEN умови іншого TYPEOF виразу.
- TYPEOF не допускається в SELECT з semi-join запитом. Ви можете використовувати TYPEOF в SELECT запиті outer запиту, який містить semi-join запити. Наступний приклад не валідний:
SELECT Name FROM Account
WHERE CreatedById IN
( SELECT
TYPEOF Owner
WHEN User THEN Id
WHEN Group THEN CreatedById
END
FROM CASE )
Наступний semi-join запит є валідним, оскільки TYPEOF використовується тільки в outer SELECT:
SELECT
TYPEOF What WHEN Account THEN Phone
ELSE Name
END
FROM Event
WHERE CreatedById IN
( SELECT CreatedById
FROM Case )
- TYPEOF не можна використовувати в запитах із функціями в SELECT. Наступний приклад недійсний, оскільки TYPEOF містить FORMAT функцію:
SELECT
TYPEOF What
WHEN Account THEN Id, FORMAT(LastModifiedDate) LastModifiedDate__f
WHEN Oppty THEN Id
END
FROM Task
Натомість запустіть той самий запит без функцій, щоб отримати список ID.
SELECT
TYPEOF What
WHEN Account THEN Id, LastModifiedDate
WHEN Opportunity THEN Id
END
FROM Task
Потім запустіть другий запит із функціями в отриманому списку ідентифікаторів.
SELECT
FORMAT(LastModifiedDate) LastModifiedDate__f
FROM Account
WHERE Id in RetrievedIdList
- TYPEOF не можна використовувати в запитах з GROUP BY, GROUP BY ROLLUP, GROUP BY CUBE, та HAVING.
Сьогодні ми з вами дізналися про те, що таке поліморфні поля, як їх відрізнити від полів відношення та розглянули приклади використання поліморфних полів. Сподіваюся, це прояснило більшість основних питань, пов’язаних із поліморфними полями. Якщо цей приклад для вас був цікавий, ставте лайки 
Всім па-па!