Understanding R12.2: Dependency between Non Editionable Objects and Editionable Objects

July 5, 2016

Oracle Applications release 12.2 implemented the Online Patching feature and the new development standards required to support it. These standards are based on the need to address several constraints in the Online Patching architecture, one of which is the dependency of Non Editionable objects to Editionable objects. Is it possible?

Short answer: No, it’s not. A Non Editionable object cannot have multiple versions of itself, like Editionable objects do. So for example, you cannot have two versions of a table or an index.

To illustrate this point, let’s imagine you have an index that is based on a function. You calculate the index key values based on the result of a function that calculates the values of the columns in the rows indexed. Database functions are Editionable objects, so we can have multiple versions of a same function. Now, how could a function-based index (of which we only have one version) depend on a function that has multiple versions? Which database function would the index use?

You can easily see the impossibility here, which is why the dependency of Non Editionable objects to Editionable objects is not allowed. Basically, every time you have an object of which you can only have one version, this object cannot depend on an object that can have multiple versions:

  • Public synonyms (non-Editionable) cannot depend on an Editionable object like a view. So you cannot have a public synonym point to a view. Fortunately there’s a workaround for this
  • A materialized view (non-Editionable object) cannot depend on an Editionable object, like a view or a function. This is important as many times you create views based on other views, or use functions to calculate some values (like reading the organization id profile value).
    Fortunately there’s a workaround for this too
  • You cannot have a table (non-Editionable object) with a user-defined type, which is an Editionable object. This is not a common situation but if you defined custom types to manage certain types of information in your application, this can be a huge problem. There’s a workaround here too
  • Finally, a non-Editionable piece of PLSQL code cannot reference an Editionable PLSQL program. This means you cannot call Oracle Applications packages (Editionable objects) from code from a 3rd party application installed in your database unless it also deals with the editioning features. And this includes applications built with Oracle tools, like Application Express, or some very popular testing tools

For more on R12.2 topics check our other posts.

Subscribe to our blog

Related Posts