Databases Reference
In-Depth Information
Because the developers don't have direct access to the production systems, administrators or technical
support personnel will perform the installation for them.
Parallel Development on Different Application Versions
Sometimes it is necessary to work on different versions of an application at the same time. Typically this
is required when some developers are fixing urgent issues while the rest of the team is already working
on the next release, whether issues happen in production or during the test phase.
How can you make sure that they don't interfere with each other? Regarding the objects in the
application schema, you could just create another schema as a duplicate. You could modify the objects
in the two schemas independently of each other using the respective DDL statements (e.g., alter table x,
add column (y number)) and store them in the file system. Using a version control system, we use
standard techniques like branching and merging to manage different versions of the source code.
For an APEX application, this standard approach is a lot more difficult. In Listing 9-1 you can see the
definition of a list of values in APEX from an application export file.
Listing 9-1.
Definition of a List of Values from an APEX Application Export File
wwv flow api.create list of values (
p id => 5017504088986621 + wwv flow api.g id offset,
p flow id => wwv flow.g flow id,
p lov name => '1 0',
p lov query=> '.'||to char(5017504088986621 + wwv flow api.g id offset)||'.');
APEX uses a metadata approach which is heavily dependent on numerical IDs for referencing
related objects. The most obvious solution would be to make a copy of the application and modify both
independently of each other. Since APEX will generate the object IDs for new objects automatically, you
will quickly have to deal with conflicting IDs (the same ID for different objects in the two applications),
which will make it impossible to merge the applications later.
What Is the Current Status?
When you maintain an application for many months or years you will often have to figure out the
current status of the different servers, database schemas, APEX applications, and so forth. You need
versioning information in all relevant elements to make sure you can immediately determine which
versions are installed where. This includes the installation scripts for the database objects and all
relevant APEX files (application export, Javascript, and CSS files).
In addition, you need to record all scripts that have been executed in the database schema (either
DML or DDL) as well as the currently installed version number of the database back end.
It is really helpful to understand when the application or the data has been changed, especially
when you discover a problem in the production system. For example, you see an erroneous row in a
table which is a result of a known problem that has been fixed in a subsequent release. If you know
exactly when you installed the fix in the production system you can determine whether the current
problem is related to that old problem or if the fix didn't work as expected.
Which Requirements Were Implemented in This Release?
No developer likes to write documentation, but for each new release you have to compile a list of
changes (either newly implemented functionality or bug fixes) for your client and users. You especially
need to communicate the changes when you collaborate with a test team to thoroughly test the new
release. This is not only true for the finally shipped release but also for each incremental release
