Developers/Setup tasks/Implementation/Dependencies

The setup tasks must be executed in a specific order to work correctly. Declaring the dependencies is a more flexible way to determine this order than using fixed numbers or the alphabetic order. As existing tasks shouldn't be changed to maintain full backward compatibility, it's necessary to allow new core setup tasks to declare which tasks must run before and which ones have to be executed afterwards. Also, extensions must be able to do the same because it wouldn't make sense for the core tasks to contain all dependencies of all existing extension tasks. The reason for extension setup tasks to be placed between core tasks is, that not only core tasks can create or update tables. If the setup task in your extension adds a column to a table it should be placed before the task which inserts the unit test data.

Note: The name of the dependency is the string behind MW_Setup_Task_, so for MW_Setup_Task_TablesCreateMShop it would be TablesCreateMShop. For this reason don't change the name of an existing task because then the required dependency information is lost.

Important: Declare only pre- and post-dependencies your task really depends on. Otherwise, the setup process will stop sooner or later because it can't resolve circular dependencies.

Pre-dependencies
To find out which tasks must be executed before new ones, have a look at the SQL statements that should be executed. All tables, columns and indexes that are affected or referred by the statements should be taken into account when searching through the existing setup tasks. Most often you only have to look at the core tasks of the same domain to find all setup tasks that must be a pre-dependency to the new one.

Examples for pre-dependencies:
 * OrderAddBaseAddressAddrId depends on OrderRenameTables (the comment column is added to mshop_order_base_address but the original name of the table was mshop_order_address)
 * MShopAddLocaleData depends on TablesCreateMShop (the languages and currencies can only inserted if the tables have been created)
 * AttributeModifyIndex has no dependencies (dropping the index if available depends on nothing else, especially not on the existence of the table itself)

Post-dependencies
Post-dependencies are a little bit different because you have to know what the task will do. Most often, post dependencies are used for the TablesCreateMShop and CatalogRebuildIndex or similar named tasks. The first one creates all new tables and indexes. Tasks modifying existing tables won't do anything if the tables are not yet available so adding TablesCreateMShop as post-dependency will speed up the process for new installations.

Examples for post-dependencies:
 * CatalogAddCode should run before TablesCreateMShop (to speed up the setup process)
 * ProductAddTestData should run before CatalogRebuildIndex (so the test products are written into the catalog index)

<< Previous: Implementation - SQL statements | Next: Implementation - Process the updates >>