Architecture - Expert Oracle Application Express - page 520

Any number of workspaces can be created in an instance of APEX. Workspaces can be created
manually, by logging in to the instance administration application, or Application Express can be set up
to allow self service, where application developers can request a workspace. Each workspace is assigned
one or more physical database schemas. Figure 12-9 illustrates workspace-to-schema assignment
options. Typically, each workspace is assigned one schema, and no two workspaces have access to the
same schema.
Figure 12-9 . APEX workspaces
The physical tables that manage the APEX metadata are “striped” with a numeric workspace
identifier (internally called SECURITY GROUP ID ). This workspace ID isolates each workspace's application
metadata, similar to how the Oracle data dictionary isolates one database schema from another. Also,
like the Oracle data dictionary, APEX provides a number of views, including APEX APPLICATIONS ,
APEX APPLICATION PAGES , APEX APPLICATION PAGE REGIONS , and more. These views can be accessed from
other tools like Oracle SQL Developer and Oracle SQL Plus. When used outside of APEX, the query,
SELECT APPLICATION NAME FROM APEX APPLICATIONS , is automatically constrained by the workspace(s)
that are associated with the current schema. Because of this, it will return different rows depending on
which database user you are connected as.
Automatic Data Manipulation Language (DML)
Within APEX, you can write your own SQL INSERT , UPDATE , and DELETE statements or, if you build forms
on tables, you can have Application Express automatically manage data manipulation for you. If you use
the “Create form on a table” wizard, you will define the application metadata needed to allow
Application Express to manage the INSERT , UPDATE , and DELETE of the data.
APEX uses an optimistic locking model. An optimistic locking model assumes that when an
application attempts to update a row, another user has not changed it since the application queried it. If
a row an application is updating is changed between the time the row is queried and the update is
posted, then the update is rejected and an error message is returned to the user. If the update was
instead allowed to succeed, the one user would unknowingly overwrite changes made by other users,
thus creating a lost update.
To make this easy and declarative, APEX provides a built-in, and mandatory, implementation of
optimistic locking using checksums. When a row is fetched using a built-in page rendering fetch process,
the fetched column values are checksumed. When the page is posted, each checksum calculated on the