第五章 – Magento资源配置
对于任何一个更新频繁的项目来说，保持开发环境和生产环境的数据库同步是件很头疼的事情。Magento提供了一套系统，用版本化的资源迁移脚本来 解决这个问题。
上一章，我们为 Helloworld Blogpost 创建了一个模型。我们直接通过SQL语句“CREATE TABLE”来创建数据表。在这一章，我们将为Helloworld模块创建一个资源配置（Setup Resource）用于创建数据表。我们也会创建一个模块升级脚本，用来升级已经安装的模块。下面是我们要做的步骤
在配置文件中添加资源配置 创建资源类文件 创建安装脚本 创建升级脚本 添加资源配置
修改Helloworld模型的config.xml
<resources>
<!– … –>
<helloworld_setup>
<setup>
<module>Zhlmmc_Helloworld</module>
<class>Zhlmmc_Helloworld_Model_Resource_Mysql4_Setup</class>
</setup>
<connection>
<use>core_setup</use>
</connection>
</helloworld_setup>
<!– … –>
</resources>
<helloworld_setup>标签是用来唯一标识我们正在创建的资源配置。虽然不是强制要求，但是我们应该使用 “modelname_setup”来命名资源配置。<module>标签的内容是“Packagename_Modulename”。最 后，<class>标签的内容就是我们将要创建的资源配置类的类名。虽然对于基本的配置来说，没有必要创建一个单独的资源配置类，但是为了更 好的理解资源配置是如何工作的，我们的例子还是创建一个单独的类。
File: app/code/local/Zhlmmc/Helloworld/Model/Setup/Mysql4/Setup.php
class Zhlmmc_Helloworld_Model_Setup_Mysql4_Setup extends Mage_Core_Model_Resource_Setup {
}
创建安装脚本
下面我们将要创建一个安装脚本。这个安装脚本包含了“CREATE TABLE”等SQL语句。这个脚本将在模块初始化的被运行。首先我们来看一下模块的配置文件
<modules>
<Zhlmmc_Helloworld>
<version>0.1.0</version>
</Zhlmmc_Helloworld>
</modules>
这一部分是所有config.xml都必须包含的。它包含了模块的名称，还有版本。我们的安装脚本的名字将基于这个版本号，“0.1.0”。创建以下文件
File: app/code/local/Zhlmmc/Helloworld/sql/helloworld_setup/mysql4-install-0.1.0.php
echo ‘Running This Upgrade: ‘.get_class($this).”\n <br /> \n”;
die(“Exit for now”);
文件路径中的“helloworld_setup”应该和上文在config.xml中添加的<helloworld_setup>一致。文 件名中的“0.1.0”就是模块的版本号。清空Magento缓存，访问任何URL，你应该看到以下内容
Running This Upgrade: Zhlmmc_Helloworld_Model_Setup_Mysql4_Setup
Exit for now
…
这说明我们的安装脚本已经被运行了。我们先不放SQL脚本在这里，先把创建一个资源配置的流程走完。移除“die()”语句，重新装载页面，你应该看到你 的Upgrade语句在页面的顶部，再次刷新页面，页面应该正常显示了。
资源版本
Magento的资源配置系统允许你直接拷贝安装脚本和升级脚本到服务器上，Magento会根据当前模块的版本自动运行相应的脚本。这样你就只需 要维护一份数据库迁移脚本。我们先来看看“core_resource”数据表
mysql> select code,version from core_resource;
+————————-+————+
| code | version |
+————————-+————+
| adminnotification_setup | 1.0.0 |
| admin_setup | 0.7.2 |
| alipay_setup | 0.9.0 |
| api_setup | 0.8.1 |
| backup_setup | 0.7.0 |
| bundle_setup | 0.1.11 |
| canonicalurl_setup | 0.1.0 |
| catalogindex_setup | 0.7.10 |
| cataloginventory_setup | 0.7.5 |
| catalogrule_setup | 0.7.8 |
| catalogsearch_setup | 0.7.7 |
| catalog_setup | 1.4.0.0.21 |
| checkout_setup | 0.9.5 |
| chronopay_setup | 0.1.0 |
| cms_setup | 0.7.13 |
| compiler_setup | 0.1.0 |
| contacts_setup | 0.8.0 |
| core_setup | 0.8.26 |
| cron_setup | 0.7.1 |
| customer_setup | 1.4.0.0.6 |
| cybermut_setup | 0.1.0 |
| cybersource_setup | 0.7.0 |
| dataflow_setup | 0.7.4 |
| directory_setup | 0.8.10 |
| downloadable_setup | 0.1.16 |
| eav_setup | 0.7.15 |
| eway_setup | 0.1.0 |
| flo2cash_setup | 0.1.1 |
| giftmessage_setup | 0.7.2 |
| googleanalytics_setup | 0.1.0 |
| googlebase_setup | 0.1.1 |
| googlecheckout_setup | 0.7.3 |
| googleoptimizer_setup | 0.1.2 |
| helloworld_setup | 0.1.0 |
| ideal_setup | 0.1.0 |
| index_setup | 1.4.0.2 |
| log_setup | 0.7.7 |
| moneybookers_setup | 1.2 |
| newsletter_setup | 0.8.2 |
| oscommerce_setup | 0.8.10 |
| paybox_setup | 0.1.3 |
| paygate_setup | 0.7.1 |
| payment_setup | 0.7.0 |
| paypaluk_setup | 0.7.0 |
| paypal_setup | 0.7.4 |
| poll_setup | 0.7.2 |
| productalert_setup | 0.7.2 |
| protx_setup | 0.1.0 |
| rating_setup | 0.7.2 |
| reports_setup | 0.7.10 |
| review_setup | 0.7.6 |
| salesrule_setup | 0.7.12 |
| sales_setup | 0.9.56 |
| sendfriend_setup | 0.7.4 |
| shipping_setup | 0.7.0 |
| sitemap_setup | 0.7.2 |
| strikeiron_setup | 0.9.1 |
| tag_setup | 0.7.5 |
| tax_setup | 0.7.11 |
| usa_setup | 0.7.1 |
| weee_setup | 0.13 |
| widget_setup | 1.4.0.0.0 |
| wishlist_setup | 0.7.7 |
+————————-+————+
63 rows in set (0.00 sec)
这张表包含了系统中所有安装的模块和模块的版本。你可以看到我们的模块
| helloworld_setup | 0.1.0 |
Magento就是根据这个版本来判断是否需要运行升级脚本的。这里“helloworld_setup”版本“0.1.0”，而我们的安装脚本也是 “0.1.0”，所以Magento不会再运行该脚本。如果你需要重新运行安装脚本（在开发的时候常用到），只要删除表中相应模块的数据就行了。让我们来 试试看
DELETE from core_resource where code = ‘helloworld_setup’;
这次我们将通过安装脚本来创建数据表，所以我们也要删除之前创建的数据表
DROP TABLE blog_posts;
添加以下代码到我们的安装脚本
$installer = $this;
$installer->startSetup();
$installer->run(”
CREATE TABLE {$installer->getTable('helloworld/blogpost')} (
blogpost_id int(11) NOT NULL auto_increment,
title text,
post text,
date datetime default NULL,
timestamp timestamp NOT NULL default CURRENT_TIMESTAMP,
PRIMARY KEY (blogpost_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO {$installer->getTable('helloworld/blogpost')} VALUES (1,’My New Title’,’This is a blog post’,’2009-07-01 00:00:00′,’2009-07-02 23:12:30′);
“);
$installer->endSetup();
清空Magento缓存，访问任何URL，你应该发现“blog_posts”表又被建立了，拥有一条数据。
解剖配置脚本
让我们来分析一下上面的代码。【译者注：作者在文中混用了“install script”，“upgrade script”和“setup script”。我在翻译的时候尽量分清。配置脚本包含了安装脚本和升级脚本。】先看第一行
$installer = $this;
这个“$this”是什么呢？每一个配置脚本都是属于某个资源配置类（Setup Resource class），比如上面我们创建的“Zhlmmc_Helloworld_Model_Setup_Mysql4_Setup”。这些脚本都是在这个资源 配置类的上下文环境中运行的。所以“$this”就是指资源配置类的实例。虽然不是强制的，但是大多数核心模块的资源配置类都用“$installer” 来代替“$this”，就和我们这里做的一样。虽然我们说不是强制的，但是我们最好还是遵守这个约定，除非你有一个很好的理由。
接下来看下面两个调用
$installer->startSetup();
//…
$installer->endSetup();
如果你打开“Mage_Core_Model_Resource_Setup”类（也就是我们创建的资源配置类的父类）的源码，你将会看到这两个方法做了 一些SQL准备工作
public function startSetup()
{
$this->_conn->multi_query(“SET SQL_MODE=”;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=’NO_AUTO_VALUE_ON_ZERO’;
“);
return $this;
}
public function endSetup()
{
$this->_conn->multi_query(”
SET SQL_MODE=IFNULL(@OLD_SQL_MODE,”);
SET FOREIGN_KEY_CHECKS=IFNULL(@OLD_FOREIGN_KEY_CHECKS,0);
“);
return $this;
}
真正的配置逻辑是在“run”方法中
$installer->run(…);
这个方法的参数就是你要运行的SQL。你可以包含任意数量的SQL，用分号隔开。你可能注意到了以下语句
$installer->getTable(‘helloworld/blogpost’)
【译者注：你的第一反应是什么？是不是联想到config.xml里面下面这段代码？
<helloworld_mysql4>
<class>Zhlmmc_Helloworld_Model_Resource_Mysql4</class>
<entities>
<blogpost>
<table>blog_posts</table>
</blogpost>
</entities>
</helloworld_mysql4>
这里“helloworld/blogpost”就是我们要创建的数据表的URI。Magento先用“helloworld”找到模块，得到资源模块 “helloworld_mysql4”，然后在资源模块下面通过“blogpost”找到类名“blog_posts”。】很显然，你可以用常量 “blog_posts”来代替调用“getTable”，但是调用这个方法可以保证即使用户更改了配置文件中的数据表名字，你的配置脚本依然能运行。 “Mage_Core_Model_Resource_Setup”类有很多类似这样的帮助函数。学习这些函数最好的方法就是阅读Magento核心模块 的资源配置类代码。
模块升级脚本
上面我们说过配置脚本包括安装脚本和升级脚本。讲完了安装脚本，我们来讲升级脚本。安装脚本是在第一次安装模块的时候使用的，而升级脚本顾名思义就 是在升级模块的时候使用。Magento的资源配置系统使用了版本化的方式来升级模块。
首先要说明的是，在安装模块的时候Magento会执行一次安装脚本，然后Magento再也不会为该模块执行任何安装脚本了。如果你要更新模块的数据表 就要通过升级脚本来执行。除了命名方式以外，升级脚本和安装脚本并没有太大的不同。
创建升级脚本如下
File: app/code/local/Zhlmmc/Helloworld/sql/helloworld_setup/mysql4-upgrade-0.1.0-0.2.0.php
echo ‘Testing our upgrade script (mysql4-upgrade-0.1.0-0.2.0.php) and halting execution to avoid updating the system version number <br />’;
die();
升级脚本和安装脚本是放在相同目录下面的，但是命名方式不同。首先是“upgrade”关键词。其次，你会发现这里我们有两个版本号，用“-”分开。第一 个版本号“0.1.0”是指从哪个版本升级（起始版本），第二个版本号“0.2.0”是指要升级到哪个版本（目标版本）。
清空Magento缓存，请求任何一个URL，你会发现没有任何配置脚本被运行。那是因为，第一，我们已经运行过安装脚本，第二，目前我们模块的版本是 “0.1.0”，所以Magento不会运行我们要升级到“0.2.0”的升级脚本。要让Magento运行这个升级脚本，我们得修改配置文件中的版本号
<modules>
<Zhlmmc_Helloworld>
<version>0.2.0</version>
</Zhlmmc_Helloworld>
</modules>
清空Magento缓存，重新请求页面，你会看到升级脚本的输出。【译者注：作者在这里引入了第二个升级到“0.1.5”的升级脚本，我觉得并没有必要， 我来直接总结一下Magento升级的步骤
从数据表“core_resource”中获得当前模块的安装版本 从配置文件中获得当前模块的版本 如果两个版本一样，那么什么都不做 如果#2的版本号小于#1的版本号，我也不知道Magento会干什么，理论上是不可能出现的情况 如果#2的版本号大于#1的版本号，那么开始升级程序 在配置脚本文件夹内（在上面的例子中是“helloworld_setup”）把所有升级脚本加入队列 在队列内，按照升级脚本的起始版本排序，升序 循环队列 如果队列中当前脚本的起始版本不等于“core_resource”数据表中当前模块的版本号，那么跳过该脚本 如果队列中当前脚本的起始版本等于“core_resource”数据表中当前模块的版本号并且目标版本小于等于#2的版本号，那么执行该脚本。 循环队列结束，升级结束
值得注意的是第10步，每次执行一个升级脚本，“core_resource”数据表中的版本号都会被更新。所以如果我们有两个升级文件 “0.1.0-0.1.5”和“0.1.0-0.2.0”，只有一个升级文件会被执行。
】
下面我们来为升级脚本添加实质内容
$installer = $this;
$installer->startSetup();
$installer->run(”
ALTER TABLE {$installer->getTable('helloworld/blogpost')}
CHANGE post post text not null;
“);
$installer->endSetup();
清空Magento缓存，刷新页面，你应该看到升级脚本的输出。如果没有，请你对照上面讲的Magento升级的步骤查找错误。
总结
这一章我们讲解了Magento是如何处理模块数据表的安装和升级的。Magento的资源配置系统使用版本化的升级脚本，这样就保证了不同版本的 模块可以使用同一套的升级脚本，便于维护。我们后面的章节也会提到这种升级方式的优点，特别是对于使用EAV模型的模块来说，这个优点更为明显。
第六章 – 高级Magento模型
我们讲过Magento有两种模型，简单模型和EAV（Entity Attribute Value）模型。上一章我们讲过所有的Magento模型都是继承自Mage_Core_Model_Abstract / Varien_Object。简单模型和EAV模型的区别在于资源模型（Model Resource）。虽然所有的资源模型都最终继承“Mage_Core_Model_Resrouce_Abstract”，但是简单模型是直接继承 “Mage_Core_Model_Mysql4_Abstract”，而EAV模型是直接继承 “Mage_Eav_Model_Entity_Abstract”。
Magento这么做是由它的道理的。对于大部分开发人员或者用户来说，他们只需要知道一系列的方法能够操作模型，获得数据，数据到底是如何存储的并不是 很重要。
什么是EAV模型？
Wikipedia是这么定义的：
EAV（Entity-Attribute-Value）模型，也作Object-Attribute-Value模型或者开放模型是 一种数据模型。这种数据模型常常用在一个对象的属性数目不是一定的情况下。在数学上，这种模型称为松散矩阵。
换一种方式理解，EAV模型就是数据表的一种泛化。在传统的数据库中，数据表的列的数量是一定的
+——————+
| products |
+——————+
| product_id |
| name |
| price |
| etc.. |
+——————+
+————+—————-+——————+———+
| product_id | name | price | etc… |
+————+—————-+——————+———+
| 1 | Widget A | 11.34 | etc… |
+————+—————-+——————+———+
| 2 | Dongle B | 6.34 | etc… |
+————+—————-+——————+———+
在上面这张表中，每一个商品都有名称，价格等等。
在EAV模型中，每一个模型都有不同的属性。这对于电子商务的应用来说是很合适的。比如说一个网店可以卖笔记本，拥有CPU速度，颜色，内存等属性，但是 网店也可以卖衣服，有颜色属性，但是没有CPU速度。即使是卖衣服的网店，也有上衣和裤子之分，它们的属性也是不一样的。
有很多开源的或者商业的数据库是默认使用EAV模型的。但是一般的网站托管平台不提供这些数据库。所以Varien开发了一套基于PHP和MySQL的 EAV系统。换句话说，它们在传统的关系型数据库上面开发了一套EAV数据库系统。
在使用的时候，EAV模型的属性是会分布在不同的MySQL数据表中。
