23.1 Identifying Application Artifacts
Understand APEX application artifacts as exportable metadata snapshots you can compare, version, and restore.
An APEX application is a collection of definitions stored in Oracle Database. Unlike file-based apps, its pages, components, and logic exist as metadata that the APEX engine reads to render pages on demand. An APEX workspace provides the context for one or more applications and links to one or more schemas. Within a workspace, an application consists of many components: pages, reports, forms, navigation menus, LOVs (lists of values), and processes. All of these together form the application definition.
Because APEX applications are stored as metadata, the data dictionary always shows only their current state. There’s no built-in version history. When you change a page or component, the old definition is replaced. Preserving history is up to you. To track changes over time, you must export the application as text files. APEX makes this easy. It can generate a SQL script, or a set of scripts, representing the entire app in its current form. These exports are called application artifacts: human-readable snapshots of your app’s metadata that you can store, compare, and version.
The export is a portable snapshot of your app definition at a moment in time. When
you export an APEX application, by default you get one SQL file named
f<app-id>.sql containing all the application's pages,
components, and settings. You can also choose a split export. This variant
creates one file per component, organized in folders for pages, shared components, and
so on. This format works better with source control because each file reflects a single
page or component. If you change one report page, only that file differs in the next
export. This makes identifying what's changed much simpler.
These text file artifacts are your safety net and historical record. By saving each meaningful version of the application, you can recreate any past version on any instance by re-importing those files. Over time, these exports become the source of truth for your app, in effect, checkpoints in its life. In production, the database holds the version users see; in development, you shape the next version. Managing these artifacts well lets you move between versions, compare changes, and recover earlier states when needed.
Tip:
While SQL exports remain the default, evaluate whether
developer-friendly APEXlang is right for your project's source control and
external tooling needs. It's easy to read, fully editable, can be strictly validated
without a database connection using SQLcl's apex validate command,
and works well with AI coding agents. For more info, see Working with APEXlang.
Parent topic: Understanding Application Lifecycle