Database Reference
In-Depth Information
plication 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 migra-
tion from one tier to another.
If you're working on your own and are the sole person in charge of the file migra-
tion, it's good to get into the habit of maintaining a backup copy of the files you're re-
placing, 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 over-
writing 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 struc-
ture, 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 gener-
ate 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 im-
plies. If you run it against your application's “parse as” schema, it allows you to gener-
ate a SQL script containing the underlying database objects.
