Database Reference
In-Depth Information
oping with these tools, it's common practice to use a source-control tool, such as Sub-
version, to manage all the changes. Source-control tools can easily manage develop-
ment conflicts between multiple developers, because they're isolated to a single file.
APEX is different than the scripting languages just mentioned because developers
don't work with files. All the information is stored in tables in the database. When you
create an export of an application, you get a single SQL file that load the metadata for
the application into these tables. Because APEX stores its content in the database, you
can't use traditional source-control tools to manage conflicts when developing in teams
with multiple developers.
APEX Conflicts
To demonstrate a development conflict in APEX, imagine that you have two deve-
lopers, Mina and Natalie, working on the same page in an application. If they're both
adding and modifying page components at the same time, the page may not behave as
expected for either of them.
APEX prevents developers from modifying the same object at the same time by per-
forming
optimistic locking
.
Table 13-1
shows the sequence of events that occurs as the
two developers edit the same object. You can see at the end how APEX prevents
Natalie from overwriting the changes made by Mina.
Table 13-1.
Optimistic Locking Scenario
Step
Mina
Natalie
Edit
P1_EMPNO
1
--
2
--
Edit
P1_EMPNO
Edit
help
text
to:
3
--
“Mina's
Help”
4
--
Edit help text to: “Natalie's Help”
Apply
changes
5
--
6
--
Apply changes
Receive error message:
Current version of data in data-
base has changed since user initiated update
process.
7
--
Current
row
version
identifier
=
"A08A505E601932E33BC1074BEA1A3B4C"
application
row
version
identifier
=
