Databases Reference
In-Depth Information
External Files
As mentioned previously, external files exist outside of the APEX metadata repository and usually outside the Oracle
database. In the majority of cases, these files are placed in a directory structure on the application server that provides
the HTTP services for APEX. Usually they're placed in a directory under the document root (docroot) of the domain
that is servicing APEX requests. Because they exist outside of APEX, they can't rightly be included in the supporting
objects of an application, so need to be handled separately from the other file types.
You need to keep careful track of what files your application uses and whether those files have changed during
the development of your application. Another area of concern is whether other applications, APEX or otherwise, use
these same files.
For instance, version 1 of your application may reference a JavaScript file that is stored on the application server.
During the development of version 2 of the application, you may have made changes to that file that need to be moved
from the development server to QA or production. But what if your colleague is working on another application that
uses the same JavaScript file? You must be very careful about what you change, and how you deploy it, so as not to
inadvertently affect other systems.
When migrating these files from a development to a QA or production environment, you likely need to work with
the people who are in charge of maintaining the application-server tier. They probably have a process in place for
planning the migration from one tier to another.
If you're working on your own and are the sole person in charge of the file migration, it's good to get into the
habit of maintaining a backup copy of the files you're replacing, just in case something goes wrong. You can do this
simply by renaming the file currently in use to include some type of identifier for the version. Including the date in the
filename works well for this. In Linux, the command looks something like this:
mv my_old_file.js my_old_file_2013_02_17_12_37.js
If you're using a source code control system and are tagging the file versions that are moved to production,
you may not need to take this extra step.
The key is making sure you can recover from any issues that may arise from overwriting a file. There's nothing
worse than bringing a system to its knees with no easy way to get back to the previous state.
Database Objects
It may seem that database objects should be straightforward, considering that they exist in Oracle and the SQL code
for their definition can be re-created relatively easily. And for a brand-new application, this assumption is fairly
accurate.
However, the minute an application goes live, if you need to change the table structure, you can't simply replace
the underlying tables with new versions. The users have probably entered or manipulated data in the system, and it's
your job to make sure that when new versions of the system are rolled out, the integrity of the data is maintained.
New Applications
When you're deploying a brand-new application, a couple of tools can help you generate the scripts for the underlying
database objects. The Utilities menu in the APEX SQL Workshop contains a Generate DDL tool, which does exactly
what its name implies. If you run it against your application's “parse as” schema, it allows you to generate a SQL script
containing the underlying database objects.
As shown in Figure
10-1
, the wizard asks which of the available schemas you'd like to use as the basis for the
generated script.
