\sectd\plain\pgwsxn12240\pghsxn15840\marglsxn1440\margrsxn1440\margtsxn1440\margbsxn1920\headery0\footery0\pgndec\titlepg{\headerf\pard\sl-240\sb770\sa430\plain\tqc\tx4680\tqr\tx9360 {}\tab {}\tab {}\par}{\footerf\pard\sl-240\sb770\sa910\plain\tqc\tx4680\tqr\tx9360 {}\tab {}\tab {\i\fs20 \chpgn }\par}{\headerl\pard\sl-240\sb770\sa430\plain\tqc\tx4680\tqr\tx9360 {}\tab {}\tab {\i\fs20 phpGroupWare Setup III}\par}{\footerl\pard\sl-240\sb770\sa910\plain\tqc\tx4680\tqr\tx9360 {}\tab {}\tab {\i\fs20 \chpgn }\par}{\headerr\pard\sl-240\sb770\sa430\plain\tqc\tx4680\tqr\tx9360 {}\tab {}\tab {\i\fs20 phpGroupWare Setup III}\par}{\footerr\pard\sl-240\sb770\sa910\plain\tqc\tx4680\tqr\tx9360 {}\tab {}\tab {\i\fs20 \chpgn }\par}\pard\sb373\li960\sl647\qc \b\fs49\f1 phpGroupWare Setup III\keepn\hyphpar0\par\pard\sb216\li960\sl449\qc \fs34 Miles Lott\keepn\hyphpar0\par\pard\sb200\li1680\ri720\sl260 \b0\fs20\lang1033\f0 A developer introduction to using the next generation setup application for egroupware. \hyphpar0\par\pard\sb259\s2\sl449 \b\fs34\lang1024\f1 1. Introduction\keepn\hyphpar0\par\pard\sb216\s3\sl374 \fs28 1.1. Welcome\keepn\hyphpar0\par\pard\sb144\li960\sl260 \b0\fs20\lang1033\f0 Thanks for taking the time to look over this document. If you are a developer who is new to egroupware, this document will be invaluable to your success during the life of your application. This is in addition to the other fine documentation available in the phpgwapi/doc directory in your install. Even long-time phpgw developers should benefit this document. Herein, I will attempt to outline the critical steps required in order to get along with setup3, setup-TNG, or whatever we end up calling it (Hey, how about 'setup'?) \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 1.2. Overview\keepn\hyphpar0\par\pard\sb144\li960\sl260 \b0\fs20\lang1033\f0 With setup3, we introduce several new capabilities and technologies for the developer and end user alike. Michael Dean was kind enough to offer up schema_proc to form the core of an abstracted and database-independent upgrade process. This enables developers to write a single set of upgrades and table definitions, which should then work on MySQL and PostgreSQL, or any other database type we might add in the future. \hyphpar0\par\pard\sb100\li960\sl260 Adding to this to control the process was a good chunk of the old setup program, written by Dan Kuykendall (Seek3r). Dan had everything to do with the new dependencies support and with the format of the $setup_info array in setup3. \hyphpar0\par\pard\sb100\li960\sl260 Setup3 adds multi-language support for the setup application, a long missed feature, I would imagine. \hyphpar0\par\pard\sb100\li960\sl260 Setup3 gives each application developer control over their application install and upgrade processes, while giving them access to work within a realm formerly owned by only the former core egroupware applications. Yes, this is extra work for the developer. But it is hoped that setup3 is also viewed as a tool that can truly enhance the development process. \hyphpar0\par\pard\sb100\li960\sl260 OK. Let's dive right in... \hyphpar0\par\pard\sb259\s2\sl449 \b\fs34\lang1024\f1 2. Application setup files\keepn\hyphpar0\par\pard\sb173\li960\sl260 \b0\fs20\lang1033\f0 The files in this section are contained within each application/setup directory. Every app will some of these files in order to operate with setup3. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 2.1. setup.inc.php (Required)\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 2.1.1. Basic information\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 The values in this section must be used by all applications. \hyphpar0\par\pard\sb100\li960\sl260 The first section of setup.inc.php defines the very basic and yet critical information about the application. Take a look at the following section: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $setup_info['addressbook']['name'] = 'addressbook';\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 'name' is used throughout egroupware, typically in $phpgw_info flags such as 'currentapp' or as the 'app_name' almost everywhere else. \hyphpar0\par\pard\sb100\li960\sl260 'title' would be used in the navbar, admin, preferences, as well as in the application itself. \hyphpar0\par\pard\sb100\li960\sl260 The 'version' string defines the version of the application and table code. This would be incremented whenever you create a new upgrade function, and typically only for table modifications. If the change is significant from the last code update, you could increment this here also. Incrementing this version string is not trivial, so please do read the rest of this document for more information about that. \hyphpar0\par\pard\sb100\li960\sl260 'app_order' determines the order of applications in the navbar. If the number you set here is the same as is set for another app, the app whose 'name' is first in the English alphabet would appear first. Smaller numbers show closer to the top or left end of the navbar, depending upon the layout. \hyphpar0\par\pard\sb100\li960\sl260 The 'enable' string is used by the egroupware API to determine whether an application is disabled, enabled, or enabled but hidden from the navbar. Most applications will want this set to a value of 1 (enabled). The notifywindow app sets this to 2, which keeps it off the navbar. An enable of 0 would disable the app by default. There is one other special case, 3, which is used primarily by the API itself. From the perspective of setup3, the API is an application just like any other application. By setting the 'enable' flag to 3, the API is still enabled, but will not be assignable to a user as a real application. It will thereby be hidden from the admin for application and user/group editing. \hyphpar0\par\pard\sb200\s4\li960\sl312 \b\fs24\lang1024\f1 2.1.2. Table info\keepn\hyphpar0\par\pard\sb200\s5\li960\sl260 \fs20 2.1.2.1. Only applications with database tables will use entries in this section.\keepn\hyphpar0\par\pard\sb100\li960\sl260 \b0\lang1033\f0 The next section of $setup_info values is an array defining all of the application's database tables: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $setup_info['addressbook']['tables'] = array(\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 This is a simple array, and must list accurately the current table names you are using in your application. This list will match a much more complex array of table specifications, as you will see below. \hyphpar0\par\pard\sb200\s4\li960\sl312 \b\fs24\lang1024\f1 2.1.3. Hooks\keepn\hyphpar0\par\pard\sb200\s5\li960\sl260 \fs20 2.1.3.1. Some applications will use this section.\keepn\hyphpar0\par\pard\sb100\li960\sl260 \b0\lang1033\f0 The hooks array part of $setup_info contains a simple list of hooks the application will use: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $setup_info['addressbook']['hooks'][] = 'preferences';\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 Here we also note a different method of 'stuffing the array.' In any case, this list of hooks will be required soon in order for your hook_admin.inc.php and other files to work. This is being done to cut down on the manual directory listing and file_exists loops done currently to discover hook files. Other than 'preferences' and 'admin', 'home', 'manual', 'after_navbar' and 'navbar_end' are all valid hook entries. \hyphpar0\par\pard\sb200\s4\li960\sl312 \b\fs24\lang1024\f1 2.1.4. Dependencies\keepn\hyphpar0\par\pard\sb200\s5\li960\sl260 \fs20 2.1.4.1. All applications will have at least one entry here.\keepn\hyphpar0\par\pard\sb100\li960\sl260 \b0\lang1033\f0 The final section, or array of data, is a listing of the other applications your application requires in order to function: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $setup_info['addressbook']['depends'][] = array(\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 This is the standard dependency array for all egroupware applications. It states that this application requires the phpgwapi, and lists the versions with which versions this app is compatible. This list would need to be appended upon each new API release, assuming your application is compatible with this new API version. You may list other applications here, e.g. your app might depend upon 'email' in order to work properly. \hyphpar0\par\pard\sb100\li960\sl260 Do NOT list applications here without considering this: If you do list an application here, and your app does not really require it, your application will not install unless that other application is already installed. This is handled normally within the install/upgrade process loops, which will install only applications whose dependencies are satisfied. Using a multipass function, the applications are installed in the correct order to ensure that dependencies are resolved. In all cases, the API would be installed first in every new install or upgrade, since all applications depend on the API. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 2.2. tables_baseline.inc.php (Recommended)\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 2.2.1. Any application that has at least one upgrade routine will have this file.\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 The tables_baseline file represents the earliest supported version of an application's tables. This file is used only in the upgrade process, and is critical to its success. It contains an array of database-independent table, field, key and index definitions. \hyphpar0\par\pard\sb100\li960\sl260 This array is formatted for use by the class.schema_proc_array.inc.php file in setup3. See the tables_update section below for more detail about schema_proc, but for now, here is a simple table definition in this format: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $phpgw_baseline = array(\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 This multi-dimensional array contains 1 subarray with 5 subs of its own. The first array ('skel' above) defines the table name. Below that are 5 sections, 'fd' for field definitions, 'pk' to define primary keys, 'fk' to define foreign keys, 'ix' to define indexed fields, and 'uc' to define columns that require unique values. In the above example, the table 'skel' has 6 fields (skel_id, skel_owner, skel_access, skel_cat, skel_des, skel_pri), and 'skel_id' is defined also as the primary key for this table. More information on this array is below. But, this format was chosen as an available solution for defining tables and fields without having to maintain seperate files for different databases. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 2.3. tables_current.inc.php (Recommended)\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 2.3.1. All applications with tables will need this file.\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 The tables_current file defines the current table definition that matches the 'version' string in $setup_info as well as the current code. This file is used only for new installs, or whenever the application is removed and reinstalled. The format and name of the array in this file is the same as for the tables_baseline file listed above. In fact, whenever it is required to change your table definitions, you would start by copying the current file over to become the tables_baseline file. After having created your upgrade routines, you would then recreate the current file to match the new table definitions. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 2.4. tables_update.inc.php (Recommended)\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 2.4.1. Any application which requires an upgrade to a previous version's tables will need this file.\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 This file will be the most complex of all setup-oriented files with which you will be working. It will contain all upgrade functions capable of upgrading any possible version of your egroupware app. These upgrade routines roughly match the old setup program's upgrade functions, but the use of objects and the methods have changed dramatically. The simplest version upgrade routine would look like: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $test[] = "0.9.3pre10";\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 This upgrade function merely updates the current version number. Note that there is not only an upgrade function, but also the setting of a value in the $test array. The name 'test' is a holdover from the old setup program, and is an arbitrary choice. However, this name must be used for the upgrade process to work. Prior to each of your upgrade functions, add the value of the previous version to $test. \hyphpar0\par\pard\sb100\li960\sl260 Now look at the function name. The name is important and should be structured as the application name and the version from which you are intending to upgrade. The '.'s in the version string are replaced with '_'. \hyphpar0\par\pard\sb100\li960\sl260 Inside the function, we global the $setup_info array. Next, we alter the version number in that array, for our application. Please be careful to specify YOUR application name here. The very last thing we do is to return this new version to the calling function. The upgrade process relies on the value returned, since it uses this directly to determine the new version. This may appear illogical on some level, but it does work. The reason for returning this value instead of a True or 1, etc. has to do with variable scope and lifetime. In this way, even the globaling of $setup_info inside the function may have little effect on the upgrade process. But, there may be values in this array you would want to use within the function. More on that later. \hyphpar0\par\pard\sb100\li960\sl260 There is one other variable you would need if doing any database operations here. If you global $phpgw_setup, you will then have access to db and schema_proc objects and functions. The objects of interest here are: \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16\lang1024 \'95\tab \fs20 $phpgw_setup->oProc \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16 \'95\tab \fs20 $phpgw_setup->db. \hyphpar0\par\pard\sb100\li960\sl260 \lang1033 For most database work you should use the oProc object. This also has a db object that should be used for most standard phpgw API db class functions, including $db->query, next_record, num_rows, and f. The use of these for standard db operations is critical to the upgrade process. Schema_proc has a flag that can be set to determine what mode of upgrade we are in. This flag is set in the setup class during the upgrade process, and should not be altered locally. \hyphpar0\par\pard\sb100\li960\sl260 This flag is a decision on whether to alter the database or the schema_proc array. The tables_baseline file above is loaded by setup prior to running your upgrade routines. If the current installed version is greater than the current upgrade routine, we don't need to alter the database yet. But schema_proc instead alters the $phpgw_baseline array in memory. The maintenance of this array is done even when we do alter the database. Once our version number in the test array matches the currently installed version of an application, real work on the tables begins. \hyphpar0\par\pard\sb100\li960\sl260 'Why bother modifying this array at all', you may ask. The array must be maintained in order to keep current table definition status. This is used in some schema_proc functions when altering columns and tables. This is especially critical for pgsql schema_proc functions. \hyphpar0\par\pard\sb100\li960\sl260 By using the $phpgw_setup->oProc object for basic inserts and queries, we acheive the ability to run all upgrade functions in every upgrade cycle without actually altering the database until we reach the current version we actually want to upgrade. For example: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $sql = "SELECT * FROM phpgw_addressbook_extra WHERE contact_name='notes'";\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 We could have used $phpgw_setup->db or even a copy for the above activity. However, using the above method ensures that an array only upgrade does just that. If the flag was set in setup telling schema_proc to alter the array only, we do not want to touch the tables for inserts or selects yet. In this case, $phpgw_setup->oProc->next_record() returns False, and the loop is skipped. The $phpgw_baseline array does not know about table content, only table and field definitions. \hyphpar0\par\pard\sb100\li960\sl260 If the upgrade function containing this method is actually working on the tables (currentver <= the upgrade function), then next_record() is returned as the expected action of pulling the next row of data. Inside of this while loop, you can safely use $phpgw_setup->db, or preferably a copy, to do the insert/delete, etc you want to have happen here. \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $cid = $phpgw_setup->oProc->f('contact_id');\sa0\par\fi0\sb0
$update = "UPDATE phpgw_addressbook set note='" . $cvalu . "' WHERE id=" . $cid;\sa0\par\fi0\sb0
$db1->query($update);\sa0\par\fi0\sb0
$delete = "DELETE FROM phpgw_addressbook_extra WHERE contact_id=" . $cid . " AND contact_name='notes'";\sa0\par\fi0\sb0
$db1->query($delete);\sa0\par\fi0\sb0
\}\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 $db1 is a copy of $phpgw_setup->db, to avoid potential conflicts with the rest of setup's db activities. \hyphpar0\par\pard\sb100\li960\sl260 In addition to the basic API db class functions, schema_proc introduces the following special functions: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 function DropTable($sTableName)\sa0\par\fi0\sb0
function DropColumn($sTableName, $aTableDef, $sColumnName)\sa0\par\fi0\sb0
function RenameTable($sOldTableName, $sNewTableName)\sa0\par\fi0\sb0
function RenameColumn($sTableName, $sOldColumnName, $sNewColumnName)\sa0\par\fi0\sb0
function AlterColumn($sTableName, $sColumnName, $aColumnDef)\sa0\par\fi0\sb0
function AddColumn($sTableName, $sColumnName, $aColumnDef)\sa0\par\fi0\sb0
function CreateTable($sTableName, $aTableDef)\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 Please use these functions where appropriate in place of standard SQL CREATE, DROP, and ALTER TABLE commands. This will ensure that your upgrade script works for all supported databases. \hyphpar0\par\pard\sb100\li960\sl260 Of these functions, DropTable, RenameTable, and RenameColumn are pretty straightforward. Pass these the table names you wish to Drop/Rename, and schema_proc will handle the rest, including indexes and sequences, where applicable. \hyphpar0\par\pard\sb100\li960\sl260 The remaining functions require some explanation: \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16\lang1024 \'95\tab \fs20 CreateTable: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\f2 $phpgw_setup->oProc->CreateTable(\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 Does this look familiar? The array passed to CreateTable is in the format used also in tables_baseline and tables_current. Note a slight difference where the table name is being passed as a seperate argument. The second argument to the function is the table definition array, starting with 'fd'. \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16\lang1024 \'95\tab \fs20 AddColumn: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\f2 $phpgw_setup->oProc->AddColumn('phpgw_categories','cat_access',array('type' => 'varchar', 'precision' => 25));\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 Here we pass the table name of an existing table, the new column name, and a field definition. This definition is merely a slice of the table arrays found earlier in this document. \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16\lang1024 \'95\tab \fs20 AlterColumn: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\f2 $phpgw_setup->oProc->AlterColumn('phpgw_sessions','session_action',array('type' => 'varchar', 'precision' => '255'));\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 The format of this function matches AddColumn. It is also a simple case of passing the table name, field name, and field definition. \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16\lang1024 \'95\tab \fs20 DropColumn: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\f2 $newtbldef = array(\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 This is the most complicated function in schema_proc, from the user's perspective. Its complexity is necessitated by the requirement of some databases to recreate a table in the case of dropping a column. Note that the table definition array is being used yet again. The array defined here should match the table definition you want after this function has completed. Here, we are dropping the column 'acl_account_type' from the table 'phpgw_acl', and the table definition does not have this column defined. You could copy information from your tables_current file here and edit it to match the desired new table spec, less the column you wish to drop. \hyphpar0\par\pard\sb100\li960\sl260 There are additional functions within schema_proc, the majority of which are not to be called directly. They are used internally. If you do wish to investigate further, use class.schema_proc.inc.php as your guide. This master file includes the class.schema_proc_DBMS.inc.php and class.schema_proc_array.inc.php files. The DBMS files should not be used as a guide, since their functions are called from the master class, and the parameters are different from what you might expect relative to the master. \hyphpar0\par\pard\sb100\li960\sl260 PLEASE, DO NOT WRITE TO OR ALTER ANOTHER APPLICATION'S TABLES OR THE API TABLES IN YOUR APPLICATION UPGRADE FUNCTIONS! \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 2.5. default_records.inc.php (Optional)\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 2.5.1. Any application with tables that wants to load some default data will need this file.\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 The default_records file consists of a list of SQL INSERTs using the $oProc object directly: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\lang1024\f2 $oProc->query("INSERT INTO phpgw_inv_statuslist (status_name) VALUES ('available')");\sa0\par\fi0\sb0
$oProc->query("INSERT INTO phpgw_inv_statuslist (status_name) VALUES ('no longer available')");\sa0\par\fi0\sb0
$oProc->query("INSERT INTO phpgw_inv_statuslist (status_name) VALUES ('back order')");\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 In this case, the developer wanted to insert some status information, which was then used in a select box on an html form. Using the default_records file, every new install will have this data included. This file should consist of queries applicable to the tables defined in setup.inc.php and tables_current.inc.php. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 2.6. test_data.inc.php (Optional)\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 2.6.1. Any developer wanting to test the full list of upgrade routines can use this file.\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 test_data.inc.php is similar to default_records above. It is called only by schematoy.php and is never installed with a new install or upgrade. This is a developer-only file. The INSERTs here should be applicable to the tables_baseline table definitions. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 2.7. language files (Required)\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 2.7.1. All applications should have at least a file of English translations, used for their application lang() calls.\keepn\hyphpar0\par\pard\sb120\li1160\sl260\fi-200 \tx1160 \b0\fs16\f0 \'95\tab \fs20 Format of a lang file: \hyphpar0\par\pard\sb200\li960\sl234 \fs18\f2 \{phrase\}\{TAB\}\{appname\}\{TAB\}\{LANG_CODE\}\{TAB\}\{translation\}\sa0\par\fi0\sb0
\hyphpar0\par\pard\sb200\li960\sl260 \fs20\lang1033\f0 Please see the contents of the API 'languages' table for the correct setting of the LANG_CODE. \hyphpar0\par\pard\sb259\s2\sl449 \b\fs34\lang1024\f1 3. Developer Tools\keepn\hyphpar0\par\pard\sb216\s3\sl374 \fs28 3.1. sqltoarray.php\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 3.1.1. Displays the current schema_proc array defining an application's tables.\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 This web application reads the current table status live from the database. It then parses this information into a hopefully correct table definition array for schema_proc. Upon visiting this app, you are shown a list of currently installed applications with defined tables. You may then select one app or all apps, and then submit the form. From this form you may then download a tables_current file, suitable for commission to cvs. Please do check the format to make sure the definitions are correct. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 3.2. schematoy.php\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 3.2.1. Runs the full cycle of upgrades, including optional test_data.\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 This app is not beautiful, may bomb on you, and will definitely drop your application's tables. The display is similar to the user/admin tool, applications.php. You are shown a list of apps with tables. Select one app, and enter a target version. Upon submission of the form: \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16\lang1024 \'95\tab \fs20 All application tables are dropped. \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16 \'95\tab \fs20 tables_baseline.inc.php is loaded. \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16 \'95\tab \fs20 test_data.inc.php is loaded \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16 \'95\tab \fs20 tables_update.inc.php is loaded. \hyphpar0\par\pard\sb100\li1160\sl260\fi-200 \tx1160 \fs16 \'95\tab \fs20 a full application upgrade test begins. \hyphpar0\par\pard\sb100\li960\sl260 \lang1033 This will give a LOT of debugging output. Depending on your database, the process may take quite awhile. This tool should be considered as a destructive test of the full upgrade cycle. If the upgrade process is successful, you can then check the loaded test_data to see that it is still in place as expected after all the table modifications, etc. If not, it should be clear where the error has occurred. Look for the usual INVALID SQL warnings, among others. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 3.3. tools subdirectory\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 3.3.1. some utilities for sql file conversion, etc.\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 In the tools directory under setup3, there should be at least a couple of hopefully handy perl or shell scripts. These are for running on the commandline only, and might apply to converting SQL files into lang files, etc. They are not expected to be perfect, but might offer some assistance or ideas for additional utilities. Use these at your own risk or benefit. \hyphpar0\par\pard\sb259\s2\sl449 \b\fs34\lang1024\f1 4. The install/upgrade process\keepn\hyphpar0\par\pard\sb216\s3\sl374 \fs28 4.1. Overview\keepn\hyphpar0\par\pard\sb200\s4\li960\sl312 \fs24 4.1.1. Setup internal upgrade functions\keepn\hyphpar0\par\pard\sb120\li960\sl260 \b0\fs20\lang1033\f0 Setup uses a common set of functions for new installs and upgrades. These are implemented as multi-pass loops. For a single application install or upgrade, a single pass is done. For multiple application installs or upgrades, multiple passes are done automatically. The order of install in a mass install or upgrade is determined by application dependencies. The other determining factor is the order in which the application directories and setup.inc.php files are read from the filesystem. \hyphpar0\par\pard\sb216\s3\sl374 \b\fs28\lang1024\f1 4.2. New installs\keepn\hyphpar0\par\pard\sb200\s4\
