Search Results dom_doc_rev_versions




Overview
Explore in AI Chat

Overview

DOM_DOC_REV_VERSIONS is a Document Management and Collaboration (DOM) module table in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to store the versions of document revisions. In practical terms, it acts as the historical version ledger for a document revision: each time a revision is checked in, superseded, or otherwise modified, a corresponding row is recorded here to preserve the evolution of that revision over time. The object is owned by the DOM schema and comprises 11 documented columns. The ETRM documentation for this release notes that the table is "Not implemented in this database," indicating that its documentation is carried forward for reference even where the physical object is absent in the current installation.

Under the heuristic Data Vault classification mined from the foreign key structure, DOM_DOC_REV_VERSIONS is graded as standalone. In Data Vault modeling terms, this classification suggests the table be treated as an independent construct rather than as a strict hub, link, or satellite. A modeled alternative would be to treat it as a link or satellite relating a document revision to a version, since its identity is derived from the combination of revision and version rather than from an intrinsic business key of its own.

Key Information Stored

The table's columns capture both the referential context of a version and its descriptive and audit attributes.

  • DOCUMENT_ID — identifies the parent document to which the revision and version belong.
  • REVISION_ID — identifies the specific document revision that this version row belongs to.
  • VERSION_ID — the version identifier, and the column through which the table joins to VEA_VERSIONS.
  • VERSION — the human-readable version label or number associated with the row.
  • COMMENTS — free-text notes recorded against the version, typically describing the change or the reason for the new version.
  • STATUS_CODE — the lifecycle status of the version row.
  • CREATED_BY, CREATION_DATE — standard Oracle EBS audit columns capturing who created the row and when.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns capturing the last modification and the login context of that modification.

Two unique indexes are documented as business-key candidates. DOM_DOC_REV_VERSIONS_U1 covers (REVISION_ID, VERSION_ID), making the combination of revision and version the principal candidate key and confirming that a version is meaningful only within its parent revision. DOM_DOC_REV_VERSIONS_U2 covers VERSION_ID alone, enforcing that a given version is referenced at most once by this table. No single surrogate primary key column is documented separately from these unique constraints.

Common Use Cases and Queries

Typical reporting asks center on version history for a document or revision, and on audit questions about when a version was introduced and by whom. A representative query pattern joins the table to its parent document and revision identifiers:

  • Version history for a revision: select VERSION, STATUS_CODE, COMMENTS, CREATED_BY, CREATION_DATE from DOM_DOC_REV_VERSIONS where REVISION_ID = :revision_id order by CREATION_DATE.
  • All versions for a document: filter on DOCUMENT_ID to obtain the full version lineage across revisions.
  • Audit and activity reporting: aggregate on CREATED_BY or LAST_UPDATED_BY over a date range using CREATION_DATE or LAST_UPDATE_DATE.
  • Version detail enrichment: join VERSION_ID to VEA_VERSIONS to retrieve attributes held on the referenced version record.

Related Objects

The documented foreign key from DOM_DOC_REV_VERSIONS.VERSION_ID to VEA_VERSIONS establishes the primary external dependency and is the join path to version-level attributes. The REVISION_ID column is the linkage to the document revision entity, and DOCUMENT_ID ties the row back to the owning document. The unique index DOM_DOC_REV_VERSIONS_U1 reinforces the revision-to-version relationship as the operative business key. Because the ETRM metadata documents only the VEA_VERSIONS foreign key explicitly, broader relationships to document and revision master tables should be confirmed against the deployed schema before being relied upon in production queries.