Контрольні нотатки для сертифікаційного екзамену Мадженто-розробника – ч.4

 

 

Бази даних – частка в екзамені: 13%.

 

Моделі, Ресурси Моделі та Колекції

Основні поняття

Модель використовується для зберігання і обробки даних окремого об’єкту. Моделі, як правило, містять бізнес-логіку програми.

Ресурси Моделі використовуються для взаємодії з базою даних від імені Моделі. Ресурси Моделі безпосередньо виконують CRUD операції.

Колекція Моделі (Collection) працює з групою моделей та виконує (CRUD) операції для груп моделей.

 

Є два типи Моделі Magento: прості та EAV. Прості моделі взаємодіють з однією таблицею бази даних, в той час як EAV взаємодіють з декількома таблицями, використовуючи EAV шаблон проектування.

 

З’єднання з базою даних

Підключення до баз даних налаштовується у файлі config.xml:

<config>
 <global>
  <resources>
   <{identifier}>
    <connection>
     <host>{host}</host>
     <username>{username}</username>
     <password>{password}</password>
     <dbname>{database}</dbname>
     <model>{model}</model>
     <initStatements>{init commands}</initStatements>
     <type>{adapter type}</type>
     <active>{0|1}</active>
    </connection>
   </{identifier}>
  </resources>
 </global>
</config>

 

З’єднання ядра Magento (default_setup, default_read, default_write, core_setup, core_read, core_write) налаштовуються в app/etc/config.xml з обліковими даними бази даних, що зберігаються в app/etc/local.xml.

 

Робота з таблицями бази даних

Magento використовує Ресурси Моделі, щоб взаємодіяти з таблицями бази даних. Коли Модель завантажується або зберігається, вона викликає свої Ресурси Моделі для виконання операції (виконання запитів до бази даних). Назви таблиць бази даних налаштовуються у файлі config.xml і Ресурси Моделі маніпулюють ними, використовуючи вищеназвані методи, що дозволяє, наприклад, додавати префікси до всіх назв таблиць.

Таблиці називаються entities (сутностями) і налаштовуються так:

<config>
 <global>
  <models>
   <meanbee>
    <class>Meanbee_Module_Model</class>
    <resourceModel>meanbee_resource</resourceModel>
   </meanbee>
   <meanbee_resource>
    <class>Meanbee_Module_Model_Resource</class>
     <entities>
      <table_one>
      <table>meanbee_module_tableOne</table>
      </table_one>
     </entities>
   </meanbee_resource>
  </models>
 </global>
</config>

 

Це дозволяє завантажити таблицю за допомогою getTable('meanbee/table_one').

 

Виконання приєднань (join)

Наступні методи створюють з’єднання між таблицями в колекціях (collection) і роблять окремі вибірки:

• Zend_Db_Select::join()
• Zend_Db_Select::joinInner()
• Zend_Db_Select::joinLeft()
• Zend_Db_Select::joinRight()
• Zend_Db_Select::joinFull()
• Zend_Db_Select::joinCross()
• Zend_Db_Select::joinNatural()
• Mage_Core_Model_Resource_Db_Collection_Abstract::join()

 

Пошук назви таблиці

Використовуйте Mage::getModel('core/resource')->getTableName($modelEntity), щоб отримати певну таблицю для будь-якої моделі. Назви таблиць в Magento можна конфігурувати, щоб налаштовувати або перевизначати схеми бази даних, наприклад, використовуючи користувацьку таблицю.

Доступ до ресурсів моделі можна отримати за допомогою класу Mage_Core_Model_Resource_Db_Abstract і методів getMainTable() та getTable($entityName).

 

Завантаження даних

Завантаження моделі з бази даних здійснюється з використанням методу load($id, $field = null). Аргумент поля (field) дозволяє розробнику завантажувати записи з різних ключів. Якщо поле не вказано, тоді ресурс моделі визначає первинний ключ на основі параметрів, передбачених при виклику методу _init($table, $key), коли ресурсна модель конструюється.

Magento використовує Zend класи абстракції бази даних, такі як Zend_Db_Select для виконання операцій з базами даних. Ці класи дозволяють створення і виконання запитів до бази даних без необхідності використовувати конкретний синтаксис конкретного двигуна бази даних.

Коли запис витягується з Zend_Db_Select він додається до Varien_Object використовуючи setData($data). Деякі поля можуть бути серіалізовані в базі даних, тому вони десеріалізуються перед додаванням в Varien_Object.

 

Збереження даних

Збереження не таке просте, як завантаження. Першим кроком є перевірка того, чи модель має якісь зміни. Обидва методи, і setData($data), і unsetData($key, $value) встановлюють на моделі прапорець _hasDataChanges. Цей прапорець може бути використаний для визначення того, чи повинні зміни бути записаними до бази даних.

Потім починається транзакція, тож будь які зміни можуть бути скасовані в події (event), якщо в процесі збереження щось піде не так.

По-перше, виконується перевірка на унікальність. Ці запити до бази даних перевіряють, чи кожне з полів позначене як унікальні, або насправді є унікальними. Якщо знайдено дублікат ключа, тоді спрацьовує виняток.

Далі дані повинні бути підготовленні до збереження чи оновлення. Це виконується в методі prepareDataForSave(). Він викликає DESCRIBE (опис) в таблиці, щоб визначити типи стовпців і підготувати введення даних відповідно. Цей опис, звичайно, кешується. Це є причиною того, чому кеш потрібно очищувати, якщо в схему бази даних внесли зміни.

Наступна проблема полягає у визначенні, чи потрібна інструкція INSERT чи UPDATE. Це, як правило, здійснюється шляхом перевірки наявності первинного ключа, викликаючи $model->getId() == null, і тут немає ніяких винятків. Якщо не вказано ID, тоді спрацьовує автозбільшення (auto-incremented) в базі даних і потрібно витягнути його звідти. Після виконання INSERT викликається getLastInsertId() для адаптера запису, щоб додати його до моделі.

Якщо при виклику збереження в моделі було вказано ID, це або тому, що оновлення для моделі було збережено, або тому, що ідентифікатор моделі не контролюється авто-інкрементом бази даних. Якщо встановлено прапорець _isPkAutoIncrement, тоді можна використовувати UPDATE. В іншому випадку база даних повинна перевірятись на існування записів з цим ключем. UPDATE виконується, якщо є ключ, в іншому випадку виконується INSERT.

Прапорець _isPkAutoIncrement за замовчуванням встановлений в true і може бути перезаписаним на рівні підкласу.

 

Інтерфейс Колекції

Колекції Моделі забезпечують єдиний інтерфейс для виконання фільтрації і сортування моделей. Наприклад, addFieldToFlter(), addOrder() і setOrder().

 

Групові операції збереження

Коли для сутності потрібно виконати кілька операцій збереження, Magento використовує транзакції бази даних для гарантування того, що дані в базі даних залишаться у відповідному стані.

 

Фільтрація Колекції флет-таблиці

З використанням:

• $collection->addFilter()
• $collection->getSelect()->where()

 

Сортування Колекції флет-таблиці

З використанням:

• $collection->setOrder()
• $collection->getSelect()->order()

Перший спосіб заснований на інтерфейсі колекції, який виконує додаткову логіку, в той час як другий метод працює напряму з оператором вибору бази даних.

 

Події, що відслідковуються CRUD операціями:

• model_load_before
• model_load_after
• model_save_commit_after
• model_save_before
• model_save_after
• model_delete_before
• model_delete_after
• model_delete_commit_after
• {collection_event_prefix}_load_before
• {collection_event_prefix}_load_after

 

Налаштування, читання і записування ресурсів бази даних

Запит ресурсів моделі вимагає специфічного типу з’єднання з базою даних. Різні типи визначаються для надання різних дозволів по базі даних. Наприклад, read – тільки для читання, write – для зміни даних і setup – для процесів налаштування ресурсів. Тим не менш, на практиці, всі ресурси підключення Magento успадковуються від default_setup ресурсу, отже всі вони використовують те ж саме з’єднання.

 

Встановлення і оновлення скриптів

Magento використовує setup ресурсні моделі для операцій встановлення та оновлення модулів. Вони виконуються протягом ініціалізації додатку, де кожен Ресурс Встановлення дозволяє застосовувати будь-яке необхідне оновлення. Зазвичай, це робиться шляхом перевірки встановленої версії модуля з таблиці core_resource і виконання будь-яких визначених установочних скриптів.

Ресурси Встановлення визначаються в config.xml:

<config>
 <global>
  <resources>
   <{resource_name}>
    <setup>
      <module>{module_name}</module>
      <class>{setup_resource_class}</class>
    </setup>
   </{resource_name}>
  </resources>
 </global>
</config>

 

Потім встановлюються і оновлюються скрипти (звичайні PHP скрипти), що виконуються через включення їх до ресурсу встановлення, що розташований в {module_root}/sql/{resource_name}/ — для скриптів встановлення/оновлення системи. Або {module_root}/data/{resource_name}/ — скрипти для встановлення/оновлення даних.

 

Скрипти використовують наступну схему іменування:

• install-{version}.php
• update-{from_version}-{to_version}.php
• data-install-{version}.php
• data-upgrade-{from_version}-{to_version}.php

 

У старіших версіях Magento (до версій Magento 1.6 та EE 1.11), імена скриптів встановлення/оновлення містили в префіксі тип ресурсу, наприклад, mysql4.

Якщо модуль не міститься в базі даних, Модель Встановлення спочатку встановить модуль, запустивши останній за версією скрипт встановлення, а потім запустить скрипти оновлення, що йдуть наступними після версії встановлення.

Якщо версія модуля в config.xml вище, ніж версія в базі даних, Модель Встановлення виконає оновлення, запустивши всі скрипти оновлення, які мають в назві версію вищу або рівну версії в базі даних і до версії нижчої або рівній новій версії у файлі конфігурації.

 

Різні сценарії встановлення

Різні класи встановлення мають додаткові методи для допомоги у процедурах встановлення чи оновлення своїх сутностей, наприклад, ресурси встановлення EAV мають методи для створення сутностей атрибутів.

Базовими класами встановлення для Flat таблиць і EAV-сутностей є Mage_Core_Model_Resource_Setup і Mage_Eav_Model_Entity_Setup відповідно.

 

Доступні методи встановлення

Методами, які зазвичай доступні в скриптах встановлення є:

• startSetup()
• endSetup()
• getTable()
• setTable()
• updateTable()
• run($sql)

 

Методи встановлення EAV-атрибутів

• addAttribute(): забезпечує створення атрибуту, включаючи створення даних атрибутів, додавання їх в групи, набори атрибутів і налаштування опцій атрибутів.
• updateAttribute(): оновлює дані атрибутів. Метод також викликається методом addAttribute(), якщо атрибут, що додається, вже існує.

 

Відкат бази даних

Magento передбачає процедуру відкату, якщо в config.xml версія модуля нижче, ніж версія вказана в базі даних. Проте, виконання сценарію відкату насправді не реалізоване.

 

Підтримка декількох РСКБД (Реляційна система керування базами даних)

Magento абстрагує логіку двигуна бази даних за допомогою Varien_Db_Adapter_Interface. Класи двигуна бази даних реалізують цей інтерфейс, що дозволяє легко замінювати один клас двигуна на інший без необхідності переписувати всі моделі, які використовують базу даних. Фактично використовувана СУБД визначається в конфігурації з’єднання через використання поля <type>, наприклад, <type>pdo_mysql</type>.

 

Адаптація перекладу: SebWeo