Search Results dbms_dbfs_content_list_items_t




Overview
Explore in AI Chat

Overview

DBMS_DBFS_CONTENT_SPI is a SYS-owned PL/SQL package that forms part of Oracle's Database File System (DBFS) infrastructure. In the context of Oracle E-Business Suite 12.1.1 and 12.2.2, this package is not an application-facing API. Rather, it is the service provider interface (SPI) that defines the contract a DBFS content store must implement so that the generic DBMS_DBFS_CONTENT layer can operate against it. The package has no executable body of its own logic beyond the interface specification: it declares the callback entry points that a concrete store provider — for example, a SecureFiles-backed store created through DBMS_DBFS_SFS — must expose. The suffix "SPI" indicates that the routines are called by DBMS_DBFS_CONTENT on behalf of the store provider, making this package the boundary between the generic DBFS framework and a specific implementation.

The object is VALID in the dictionary and is not referenced by any other database object. It is documented as having an API classification of OTHER and exposes 37 procedures and functions, all of which relate to manipulating a hierarchical namespace of files, directories, links, and references. In EBS deployments, DBFS is typically used for attachments, exports, or file storage outside the standard APPL_TOP filesystem, and the SPI is the mechanism through which any custom or Oracle-supplied store participates in that storage layer.

Key Procedures and Functions

The documented routines fall into several functional groups. Identification and metadata routines include GETFEATURES, which reports the capabilities a store provider supports; GETSTOREID, which returns the identifier assigned to the store; GETVERSION, which reports the provider and interface version; and GETPATHBYSTOREID, which resolves a path from a store identifier. Capacity reporting is provided by SPACEUSAGE and SPACEUSAGEFULL, which return storage consumption statistics for the store. A GETPATH routine resolves path information for content.

Namespace and object creation is handled by CREATEFILE, CREATELINK, CREATEREFERENCE, and CREATEDIRECTORY, each responsible for materializing the corresponding entity type in the store. Deletion is handled by DELETEFILE, DELETECONTENT, and DELETEDIRECTORY, which remove files, generic content, and directories respectively. Lifecycle management for recoverable content is provided by RESTOREPATH, PURGEPATH, RESTOREALL, and PURGEALL, supporting targeted and bulk restore or purge operations. Finally, CREATEGETATTRVIEW and DROPGETATTRVIEW manage an attribute view object that exposes store attributes for query. Notably, the dependency list for this package includes the types DBMS_DBFS_CONTENT_CONTEXT_T, DBMS_DBFS_CONTENT_LIST_ITEMS_T, DBMS_DBFS_CONTENT_PROPERTIES_T, and DBMS_DBFS_CONTENT_RAW_T. The LIST_ITEMS type is the one surfaced by the user's search term "dbms_dbfs_content_list_items_t," and it is used by the framework when enumerating directory contents; the SPI itself exposes the interface through which a store returns those items.

Tables Accessed

The ETRM metadata documents no directly referenced tables behind APPS synonyms, which is consistent with the SPI's role: it is an interface package, and the underlying storage is defined by the store provider. Data is materialized in the store's own tables — for a SecureFiles store, these are the tables created by DBMS_DBFS_SFS — with the SPI routines operating on the type structures (context, list items, properties, raw data) passed between the generic layer and the provider rather than on application schema objects. EBS application tables are not read or written by this package.

Usage Notes

DBMS_DBFS_CONTENT_SPI is invoked indirectly. Application code, EBS forms, or concurrent programs that manipulate DBFS content normally call DBMS_DBFS_CONTENT or the DBMS_DBFS_SFS wrapper; those calls are then delegated to the store provider's SPI implementation. Because the package is owned by SYS and is not referenced by any other database object, it should be treated as internal infrastructure. Direct invocation is appropriate only when building or debugging a custom store provider, and any such work must be validated against the specific EBS 12.1.1 or 12.2.2 database release in use. The package is present and VALID in both releases covered by the metadata.