Databases Reference
In-Depth Information
Once the developer is done with the modifications, the changes are checked into the shared version
control system. If any other developer has changed parts of the modified sources, they are typically
merged by the version control system. If the version control system cannot merge the changes
automatically, the developer will have to resolve the conflicts manually. This process is usually
supported by editing tools to display the differences and merge them semi-automatically.
This typical approach doesn't work well in a database development project. The source code part is
easy, because you can completely replace a version of a package, trigger, view, or procedure with the
modified version using a simple copy command.
It gets really difficult with tables, though. When you modify a table you cannot just drop and re-
create the table. You might have referencing constraints and, most of all, you don't want to lose the
stored data.
In order to sync the local databases, each developer needs to supply a synchronizing script for all
changed objects in her local change set so that the other developers can synchronize their local database
with the changes. This is really tedious. Also, some change propagation might not work. For example,
you might have added a new row to the table
FM COUNTRIES
and supplied a synchronizing DML (data
manipulation language) script:
Insert into FM COUNTRIES (CON TITLE, CON COUNTRY CODE) Values ('France', '33');
What happens if you had already dropped the column
CON COUNTRY CODE
from this table in the
meantime? Not only the country code for France would be lost in your local table
FM COUNTRIES
, but the
statement would fail and the data for France would not be in your local table at all! Very quickly, the
different local databases would be out of sync. Another serious problem is when you are working on a
project where you have to handle large amounts of data, which is common for database developers.
This is why we advocate against the typical approach of using a local sandbox which includes a copy
of the database on the local machine. Instead, the suggested technique is to use a local sandbox only for
all files that are part of the project. For all database and APEX related development, use a shared APEX
instance, as shown in Figure 9-6.
Figure 9-6.
Shared APEX instance
