Search Results ibc_renditions_u2

Overview

The IBC.IBC_RENDITIONS table is a component of the Oracle E-Business Suite content management framework, resident in the IBC schema and designated as a VALID table object within FND Design Data. Renditions support multiple file types for a content item's attachment. A single content item may therefore expose its underlying attachment in several distinct formats simultaneously; for example, a white paper content item could carry attachments with file types such as doc, pdf, txt and html, while an image content item could carry gif, jpeg and bmp variants. Each row in IBC_RENDITIONS records one rendition — one file, in one MIME type, in one language — for a specific version of a content item.

From a Data Vault modeling perspective, the mined classification for this object is standalone. This classification is a heuristic suggestion rather than a normative design statement, but it is consistent with the table's position at the leaf of the content model: IBC_RENDITIONS holds descriptive attribute state about a rendition and does not itself serve as a central hub or as an associative link between two independent business entities. A modeler applying Data Vault conventions would most naturally treat it as a satellite attached to the content item version hub, since its granularity and change behavior are driven entirely by the parent version record.

Key Information Stored

The table is documented with fourteen columns in the 12.2.2 physical schema. The surrogate primary key is RENDITION_ID, a NUMBER column that uniquely identifies the rendition and is enforced by the IBC_RENDITIONS_PK constraint. In ETRM 12.2.2 the primary key is realized through the unique index IBC_RENDITIONS_U1 on (RENDITION_ID, ZD_EDITION_NAME), while the multi-column business key is enforced by IBC_RENDITIONS_U2 on (CITEM_VERSION_ID, LANGUAGE, MIME_TYPE, ZD_EDITION_NAME). The user query term "ibc_renditions_u2" refers to this second unique index, which is the constraint that guarantees at most one rendition exists per content item version, per language, and per MIME type.

The most significant columns are:

• RENDITION_ID — surrogate unique identifier for the rendition.
• CITEM_VERSION_ID — references the content item version for which the rendition is stored; a foreign key to IBC_CITEM_VERSIONS_B.
• LANGUAGE — the language for which this row stores data, enabling multilingual renditions.
• MIME_TYPE — the MIME type of the attachment file (for example application/pdf, text/html, image/jpeg); limited to 30 characters.
• FILE_ID — points to the BLOB in FND_LOBS that stores the attachment file for this content item version and MIME type.
• FILE_NAME — the file name of the attachment, up to 256 characters.
• SECURITY_GROUP_ID — security group identifier, with a foreign key to FND_SECURITY_GROUPS.
• OBJECT_VERSION_NUMBER — object version number used for optimistic locking.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns.

Common Use Cases and Queries

The primary operational use case is resolving the set of available file formats for a given content item version so that a calling application can present or deliver the correct rendition to an end user. A typical query joins the rendition rows to their parent version and retrieves the file pointer for downstream BLOB retrieval from FND_LOBS:

• Retrieve all renditions for a version: SELECT RENDITION_ID, CITEM_VERSION_ID, LANGUAGE, FILE_ID, FILE_NAME, MIME_TYPE FROM IBC.IBC_RENDITIONS WHERE CITEM_VERSION_ID = :p_version_id;
• Filter to a specific format and language to locate a single rendition, exploiting the IBC_RENDITIONS_U2 key: ... WHERE CITEM_VERSION_ID = :p_version_id AND LANGUAGE = :p_lang AND MIME_TYPE = :p_mime;
• Reporting on format coverage — counting distinct MIME_TYPE values per content item version to confirm that expected renditions (pdf, html, and so on) have been generated.
• Audit queries using CREATION_DATE and LAST_UPDATE_DATE to reconcile attachment changes against FND_LOBS storage growth.

Because FILE_ID is the only pointer to the binary payload, integrity checks that join IBC_RENDITIONS to FND_LOBS on FILE_ID are a common housekeeping pattern for identifying orphaned or missing attachment files.

Related Objects

The following objects are the most significant dependencies and related entities for IBC_RENDITIONS:

• IBC.IBC_CITEM_VERSIONS_B — parent content item version table; joined on CITEM_VERSION_ID = IBC_RENDITIONS.CITEM_VERSION_ID. This is the dominant join in nearly all rendition queries.
• IBC.IBC_CONTENT_ITEMS — the content item header that owns the versions, reached transitively through IBC_CITEM_VERSIONS_B.
• FND_LOBS — stores the BLOB referenced by FILE_ID; the physical attachment payload.
• FND_SECURITY_GROUPS — referenced by SECURITY_GROUP_ID, governing row-level access partitioning.
• FND_USER — referenced by CREATED_BY and LAST_UPDATED_BY for WHO column resolution.
• FND_LOGINS — referenced by LAST_UPDATE_LOGIN.
• IBC_RENDITIONS_PK / IBC_RENDITIONS_U1 / IBC_RENDITIONS_U2 — the primary key and unique index constraints that define row identity, including the business key sought by the "ibc_renditions_u2" query.
• IBC_RENDITIONS_N1 — a non-unique index, commonly used to support lookups that do not fully qualify the unique key column list.

All indexes reside in the APPS_TS_TX_IDX tablespace, while the table itself is stored in APPS_TS_TX_DATA with PCTFREE 10.