Polymorphic Fields

Всім привіт!

У цій статті ми розглянемо 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.

Сьогодні ми з вами дізналися про те, що таке поліморфні поля, як їх відрізнити від полів відношення та розглянули приклади використання поліморфних полів. Сподіваюся, це прояснило більшість основних питань, пов’язаних із поліморфними полями. Якщо цей приклад для вас був цікавий, ставте лайки :slight_smile:

Всім па-па!

7 Вподобань