Базы данных – доля в экзамене: 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')
.
Следующие методы создают соединения между таблицами в коллекциях (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
Выбор мастера для ремонта и перетяжки мебели — задача, которая требует вдумчивого подхода. Ведь от…
Выбор идеального хостинга под свой сайт может быть довольно запутанным делом, особенно когда существует так…
Чтобы избегать ошибок, нужно набираться опыта; чтобы набираться опыта, надо делать ошибки Лоуренс Питер
Краткое определение Черного SEO Черное СЕО (или Черная оптимизация) — это любая практика, целью которой…
Получение водительских прав категории C открывает двери к профессиональной деятельности, связанной с управлением грузовыми автомобилями.…