Databases Reference
In-Depth Information
Challenges
We will start by looking at the typical challenges faced by a team of developers working on an APEX
development project. You will have to face some of these challenges even when you work on the source
code all by yourself and not within a team.
Working Concurrently on the Same Source Code
A team of developers working on the same piece of software has to take care of concurrency issues. The
Oracle database itself does not have any version control software built in, so it is easy to overwrite
another member of the team's changes. For example, two developers load the source of the same
database package (Package X) into their editors. Developer A adds a function to the package and
compiles it. Now the change by Developer A is stored in the database and active. At the same time,
Developer B adds a different function to the same package but compiles it a bit later than Developer A.
When the change made by Developer B is stored in the database, the change from Developer A is lost.
You have to deal with this kind of problem when working on procedures, functions, packages, triggers,
views, object types, and the like, concurrently.
APEX does not include a version control system, either. Nevertheless, when you modify an APEX
application, you can at least set explicit locks on one or more pages you are working on. After you have
acquired a lock on these pages, other developers cannot change them until you unlock them again.
Even if you don't set explicit locks on the pages you modify, you will still be protected from
overwriting other developer's changes. APEX uses a mechanism called
optimistic locking
to prevent that.
Both Developer A and Developer B will be able to begin changing a page. When Developer A saves the
change, it will go through. When Developer B tries to save her changes as well, she will receive an error
message that the database state has been modified in the meantime. This holds true for all parts of the
application, such as pages, regions, computations, branches, lists, and breadcrumbs.
Propagating All Required Changes for a New Release
Once you are done implementing all features for the next release of your software, you need to install the
updated software on the test or production environment. You have to make sure to
propagate all the
required changes
. They can include
•
DDL statements for the creation or modification of database objects (users,
tablespaces, grants, tables, views, etc.)
•
DML statements for the manipulation of data (insert, update, delete)
•
The APEX applications
•
Files uploaded to the workspace
•
Files stored on the application server in the file system
•
Changes in the configuration of the application server (virtual directories,
compression, URL rewrites, etc.)
To deploy a release, you need to make sure that all altered objects (tables, packages, etc.) together with
the relevant data changes (insert, update, delete) are propagated from the development environment to
the test environment. You don't want to do it manually, since manual operations are error prone.
This is why we favor an approach that is almost completely based on scripts to deploy a new release
of our software. In large corporations this is quite often the only way to deliver a new software release.
