Search Results path_docid

Overview

JDR_PATHS is a table owned by the APPLSYS schema within the FND — Application Object Library product of Oracle E-Business Suite. The object is documented as VALID in both ETRM 12.1.1 and 12.2.2 repositories. Functionally, JDR_PATHS stores metadata about XML-based document paths used by the Oracle EBS diagnostic, patching, and JDR (Java Diagnostic Repository) infrastructure. Each row represents a logical path entry tied to an owner document, a path name, sequence position, and XML serialization attributes.

The heuristic Data Vault classification supplied in the metadata is standalone, meaning no foreign-key dependencies were mined that would justify modeling this table as a link between other hubs. In Data Vault terms, PATH_DOCID behaves as a natural hub-style identifier, and the remaining descriptive attributes (encoding, version, timestamps, owners) would typically be modeled as a satellite attached to that hub. Because the table has no documented inbound or outbound FK relationships, it should be treated as an independent reference object rather than as a junction or dependent entity.

Key Information Stored

The table contains thirteen documented columns, with PATH_DOCID serving as the surrogate primary key through JDR_PATHS_PK. Two unique indexes define the business-key candidates:

• PATH_DOCID — surrogate primary key; also participates in the JDR_PATHS_U1 unique index. This is the identifier users typically search for ("path_docid").
• ZD_EDITION_NAME — editioning column introduced for EBS 12.2 online patching; appears in both unique indexes.
• PATH_OWNER_DOCID — identifies the owning document; combined with PATH_NAME and ZD_EDITION_NAME forms JDR_PATHS_U2.
• PATH_NAME — the logical name of the path entry.
• PATH_TYPE — classifies the path (for example, relative vs. absolute).
• PATH_SEQ — sequence number ordering paths that belong to the same owner document.
• PATH_XML_VERSION and PATH_XML_ENCODING — XML serialization metadata.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns present on nearly all APPLSYS tables.

Common Use Cases and Queries

The most frequent access pattern is direct lookup by primary key, since PATH_DOCID is the column most often cited in support and diagnostic contexts:

SELECT path_docid, path_owner_docid, path_name,
       path_type, path_seq, zd_edition_name
  FROM  applsys.jdr_paths
 WHERE  path_docid = :p_docid
   AND  zd_edition_name = 'RUN';

Reporting queries commonly aggregate by PATH_OWNER_DOCID to enumerate all paths belonging to a document, ordered by PATH_SEQ. In EBS 12.2, edition-aware queries should always filter or qualify ZD_EDITION_NAME because two editions of the same row can coexist during online patching. Auditing use cases filter on LAST_UPDATE_DATE to track recent changes, while migration scripts compare PATH_XML_VERSION and PATH_XML_ENCODING across instances.

Related Objects

The metadata classifies JDR_PATHS as standalone, so no direct FK relationships are documented. The most significant logically associated objects are:

• JDR_PATHS_PK — primary-key constraint on PATH_DOCID.
• JDR_PATHS_U1 — unique index on (PATH_DOCID, ZD_EDITION_NAME).
• JDR_PATHS_U2 — unique index on (PATH_OWNER_DOCID, PATH_NAME, ZD_EDITION_NAME).
• APPLSYS schema objects — sibling FND/JDR metadata tables sharing the WHO columns and editioning convention.
• AD_ZD_EDITION infrastructure — governs ZD_EDITION_NAME values used by this table under online patching.
• FND_LOOKUPS / FND_APPLICATION — commonly joined to resolve application context for JDR metadata reporting.

Because the table is edition-enabled, any downstream view or API interacting with JDR_PATHS must respect the ZD_EDITION_NAME filter to avoid duplicate or stale rows.