Databases Reference
In-Depth Information
Once the sources are extracted into the table
XLIB DDL STATEMENTS
you can remove all objects that
are irrelevant by deleting the respective rows from the table. Next, you can spool all relevant objects into
the file system with another set of scripts.
Using this script-based approach, you have a lot of flexibility on how to structure the file system as
well as which statements will be grouped together into which file. Also, you can much better control the
naming of the files. This is clearly an advantage over the built-in methods which the development
environments provide out of the box. Furthermore, you don't have to make any manual adjustments to
the export, which is always error prone.
Once the sources are extracted from the database and spooled into the file system, you may have
new or changed objects. Subversion will tell you exactly which database objects have been modified or
newly created, as shown in Figure 9-19.
Figure 9-19.
Changes highlighted by TortoiseSVN/Subversion
All the changed files can then be copied into the current patch directory. This way you have all the
scripts for the relevant database objects included in your patch.
After that, you still need to export the current APEX application into the directory
patch/<version>/apex
. The file has the structure
f
<application id> <application
name>
v
<version>
.sql
, for example,
f20100629 alm demo v1.0.0.3
. You will need all relevant CSS,
Javascript, and other files as well.
Installation in the Test Environment
To make the application available to the test team and the business users you have to install it on the test
system. You want to make the overall approach as safe as possible by minimizing room for errors. For
this reason, we advocate an almost completely script-driven approach.
How can you make sure your scripts run flawlessly in production? You have to make sure that you
resolve all issues when installing on the test system. The problem is, once you run any script for the first
time, the state of the database has changed. Even if you fix the issues in the script, you can never be sure
that it will run flawlessly in production too.
Once the scripts have been fixed and all issues resolved, you need another final test on a clone of the
production system. This test must run flawlessly. To accomplish that, you have to reset the state in the
database and undo the changes caused by running the patch script. You could restore a previous backup
from the database, but that might be quite problematic and simply take a lot of time. Often you don't
even have the privileges to restore a backup on the test system and have to wait for the DBAs to do it.
The most convenient way is to use the Flashback feature of the Oracle Database. Once configured,
you can easily set a restore point:
