In any fast iteration of the project, how to ensure the development and production (current network) database synchronization is a very headache. Magento provides a system to create a resource migration version that can help us deal with the problems that are constantly encountered during development. Www.2cto.com the last time we created the Weblogpost model. This time, we execute the create TABLE directly. We will not create a setup Resource with our module, and the resource will create a table. We will also create an upgraded script that will upgrade the already installed module. Overall 1. Add Setupresource 2 to config. Create the Resourceclass file 3. Create Installerscript 4. Create upgrade Script Add Setup resource we are Section adds the following xstarx_weblog xstarx_weblog_model_resource_mysql4_setup C ore_setup tags are used to uniquely represent setupresource. The use of Modelname_setup is often encouraged. Xstarx_weblogThe pachagename_modulename of our module should be included under the label. At last Xstarx_weblog_model_resource_mysql4_setup Should contain the name of the Setup resource class that we want to create. For basic scripts, it is not necessary to create your own classes, but to do so, you can be more flexible later. After adding the configuration, clear the cache, and load Magento Site, you will find an exception fatalerror:class ' Xstarx_weblog_model_resource_mysql4_setup ' not found in Magento tried to instantiate the class we declared in config, but it was not found. We need to create such a class file app/code/local/xstarx/weblog/model/resource/mysql4/setup.php Classxstarx_weblog_model_resource_ Mysql4_setup Extendsmage_core_model_resource_setup {} Now reloads the Magento site, the exception disappears. Create an installation script next, we'll create the installation script. The script contains the previous CreateTable statement. First, let's look at the CONFIG. 0.1.0 This section is required in the configuration file, which indicates the module and also tells the version. The installation script is based on the good version. Create a file in the following location app/code/local/xstarx/weblog/sql/weblog_setup/mysql4-install-0.1.0.php Echo ' Running this Upgrade: '. get_ Class ($this). " \ n
\ n "; Die ("Exit for Now"); The weblog_setup part of the path matches the. config file 。 The 0.1.0 section matches the version of module. Clear the cache, load the page and you can see Running this upgrade:alanstormdotcom_weblog_model_resource_mysql4_setup Exit for now ... This means that our update script executes. Finally we put the SQL update file here, but for the time being we focus on the setup mechanism. Remove the die declaration, echo ' Running this Upgrade: '. Get_class ($this). " \ n
\ n "; Reload the page to see the upgrade message shown in the first section of the page. Reload, the page will return to normal. Because Setup is the only time. It's impossible to always setup. Create an installation script Magenosetup resources allows us to simply place the installation script and upgrade script, and the system will execute automatically. This allows the data migration script in our system to be persisted once. Use database client to view core_resroucetable mysql> select * from Core_resource; +-------------------------+---------+ |code | Version |+-------------------------+-----+ |adminnotification_setup | 1.0.0 | | Admin_setup | 0.7.1 | | Amazonpayments_setup | 0.1.2 | | Api_setup | 0.8.1 | | Backup_setup | 0.7.0 | | Bundle_setup | 0.1.7 | | Catalogindex_setup | 0.7.10 | | Cataloginventory_setup | 0.7.5 | | Catalogrule_setup | 0.7.7 | | Catalogsearch_setup | 0.7.6 | | Catalog_setup | 0.7.69 | | Checkout_setup | 0.9.3 | | Chronopay_setup | 0.1.0 | | Cms_setup | 0.7.8 | | Compiler_setup | 0.1.0 | | Contacts_setup | 0.8.0 | | Core_setup | 0.8.13 | | Cron_setup | 0.7.1 | | Customer_setup | 0.8.11 | | Cybermut_setup | 0.1.0 | | Cybersource_setup | 0.7.0 | | Dataflow_setup | 0.7.4 | | Directory_setup | 0.8.5 | | Downloadable_setup | 0.1.14 | | Eav_setup | 0.7.13 | | 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 | | Ideal_setup | 0.1.0 | | Log_setup | 0.7.6 | | Newsletter_setup | 0.8.0 | | Oscommerce_setup | 0.8.10 | | Paybox_setup | 0.1.3 | | Paygate_setup | 0.7.0 | | Payment_setup | 0.7.0 | | Paypaluk_setup | 0.7.0 | | Paypal_setup | 0.7.2 | | Poll_setup | 0.7.2 | | Productalert_setup | 0.7.2 | | Protx_setup | 0.1.0 | | Rating_setup | 0.7.2 | | Reports_setup | 0.7.7 | | Review_setup | 0.7.4 | | Salesrule_setup | 0.7.7 | | Sales_setup | 0.9.38 | | Sendfriend_setup | 0.7.2 | | Shipping_setup | 0.7.0 | | Sitemap_setup | 0.7.2 | | Strikeiron_setup | 0.9.1 | | Tag_setup | 0.7.2 | | Tax_setup | 0.7.8 | | Usa_setup | 0.7.0 | | Weblog_setup | 0.1.0 | | Weee_setup | 0.13 | | Wishlist_setup | 0.7.4 | +-------------------------+---------+ Rowsin Set (0.00 sec) This table contains a list of all the installation module's, along with the corresponding versionThis. See at the end of the table | Weblog_setup | 0.1.0 | This is how Magento knows whether to re-execute the script. If all succeeds, the page will load. The Weblog_setup is already installed, so no updates are required. If you want to reload the script, you need to delete the row in the table. We can now delete the delete from Core_resource where code = ' Weblog_setup '; Then delete the corresponding table DROP table blog_posts; Then add $installer = $this in the setup script; $installer->startsetup (); $installer->run ("CREATE TABLE ' {$installer->gettable (' Weblog/blogpost ')} ' (' blogpost_id ' int (one) ' Not NULL auto_ Increment, ' title ' Text, ' post ' text, ' date ' datetime default NULL, ' timestamp ' timestamp NOT null default Current_timestamp , PRIMARY KEY (' blogpost_id ')) Engine=innodbdefault Charset=utf8; Insertinto ' {$installer->gettable (' Weblog/blogpost ')} ' VALUES (1, ' My newtitle ', ' This is a blog post ', ' 2009-07-01 00:00:00 ', ' 2009-07-02 23:12:30 '); "); $installer->endsetup (); Clear the cache, load the page, and you can see that the blog_posts is created again and has a piece of data. Create the installation script---the installation may not be so smooth, the magento1.7 below will be an error Mage_eav_exception:can ' t create table:module_entity How to solve it? Debug Createentitytables () method, you can see at the end of the $connection->begintransaction (); try {FOREACH ($tables as $tableName = + $table) {$connection->createtable ($table);} $connection->commit (); } catch (Exception $e) {zend_debug::d UMP ($e->getmessage ()); $connection->rollback (); Throw Mage::exception (' Mage_eav ', Mage::helper (' Eav ')->__ (' can\ ' t create table:%s ', $tableName)); See the underlying error: USERERROR:DDL statements is not allowed in transactions then follow up the commit function/** * Check transaction level in case of DDL Query * * @param string| Zend_db_select $sql * @throws zend_db_adapter_exception */protected function _checkddltransaction ($sql) {if (Is_string ( $sql) && $this->gettransactionlevel () > 0) {$startSql = Strtolower (substr (LTrim ($sql), 0, 3)); if (In_array ($STARTSQL, $this->_ddlroutines)) {Trigger_error (varien_db_adapter_interface::error_ddl_message, e_user_error);} }} conclusion is that MySQL does not support DDL Transaction. So rewrite the Createentitytable method in app/code/local/{companyname}/{modulename}/setup/helper.php {.../** * Remove transaction Code due to issues with errors. *//$connEction->begintransaction (); try {foreach ($tables as $tableName = = $table) {$connection->createtable ($table);} $connection->commit ();} CA TCH (Exception $e) {//$connection->rollback (); throw mage::exception (' Mage_eav ', Mage::helper (' Eav ')->__ (' can\ ' t create table:%s ', $tableName)); }} Then the problem is resolved. Setup script Anatomy Let's explain it in one line. First $installer = $this; Each installation script is executed from the Setresource class (which is what we created above). This means that the $this reference in the script is a reference to this class instantiation. If not required, most of the installation scripts in the core system are named $this Installer, and here we are. Next we see two methods $installer->startsetup (); ... $installer->endsetup (); If you look at the Mage_core_model_resource_setup class (in directory app/code/core/mage/core/resource/setup.php), you can see the following 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; The 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; Finally we execute $installer->run (...); This accepts a SQL that contains the database that was created. You can define arbitrary queries, separated by semicolons. Also, be aware that the $installer->gettable (' weblog/blogpost ') GetTable method allows us to pass the Magento Model URI and get its table name. If it is not necessary, it is performed using the secondary method. The Mage_core_model_resource_setup class contains a number of useful helper methods. The most effective learning is to study the installer scripts of Magento core. Module upgrade above describes how to initialize a data table, but how to change the structure of existing ink incense? Magento's setup resources support a simple version strategy that allows us to automate our scripts to upgrade our modules. Once Magento executes an installation script, it does not execute another installation script again. At this point, we should create an upgrade script. The upgrade script is very similar to the installation script, with only a few key differences. As a start, we create a script in the following location, xstarx/weblog/sql/weblog_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
'; Die (); The upgrade script and the installation script are in the same directory, but are slightly different. First, the file name contains upgrade. Second, there are two version numbers, separated by a "-". The first one is the source version of the upgrade, and the second is the target version of the upgrade. After clearing the cache, reload the page, but this time the script is not executed. We need to update the version information in CONFIG. * to trigger the upgrade 0.2.0 After writing the new version number, if you clear the cache, load the Web site, you can see the output. This time there is a key point to pay attention to, so do not panic to do this step. We create another file in the same directory xstarx/weblog/sql/weblog_setup/mysql4-upgrade-0.1.0-0.1.5.php echo ' Testing our upgrade script ( mysql4-upgrade-0.1.0-0.1.5.php) and not halting execution
'; This time again to clear the cache, loading the page, you can see two information. When Magento discovers that the version number information is changed, he executes all executable scripts to update the module. Although we have never created version 0.1.5, Magento will see the upgrade script and then try to execute it. Scripts are generally executed in order from low to high. The following data illustrates this mysql> select * from Core_resource where code = ' Weblog_setup '; +--------------+---------+ | Code | Version | +--------------+---------+ | Weblog_setup | 0.1.5 | +--------------+---------+ 1 row in Set (0.00 sec) We see that the version of the data table is 1.5. This is because we upgraded from 1.0 to 1.5, but did not perform a 1.0 to 2.0 upgrade. Well, after explaining this key issue, we are back to the point. Back to the script, first modify the upgrade script 0.1.0-0.2.0 $installer = $this; $installer->startsetup (); $installer->run ("ALTER TABLE ' {$installer->gettable (' Weblog/blogpost ')} ' change post post text not null;"); $installer->endsetup (); Die (the "you'll see what's this was here in a second"); Refresh the page, but nothing will happen. Why did the upgrade script not execute? 1. Weblog_setup resource is version 0.1.0 2. We want to upgrade the module to 0.2.0 3. Magento See the Upgrade module, there are two scripts to execute, 0.1.0-0.1.5 and 0.1.0-0.2.0 4. Magento loads the queue and then executes 5. Magento executes script 6 from 0.1.0 to 0.1.5. Weblog_setup resource is now 0.1.5 7. Magento executes the 0.1.0 to 0.2.0 script, execution stops 8. When the next page loads, Magento sees Weblog_set in version 0.1.5, but does not see any scripts executed from the 0.1.5 (the previous 0.1.0 start) The correct way is as follows, rename the file mysql4-upgrade-0.1.0-0.1.5.php #This goes from 0.1.0 to 0.1.5 mysql4-upgrade-0.1.5-0.2.0.php # This goes 0.1.5 to 0.2.0 Magento is capable of completing a load of two upgrades at a time. You can clear the Core_resource table information to complete the final Test update core_resource set version = ' 0.1.0 ' WHERE code = ' Weblog_setup '; Magento is based on the configuration file to perform the upgrade, so in co-development pay attention to the addition of the script.
http://www.bkjia.com/PHPjc/477854.html www.bkjia.com true http://www.bkjia.com/PHPjc/477854.html techarticle in any fast iteration of the project, how to ensure the development and production (current network) database synchronization is a very headache. Magento provides a system to create a migration version of a resource, ...
