According to the examples in the Oracle documentation, and the various web pages that describe how to implement editioning, you should create a new child edition for every code deploy. I can tell you that does not scale well at all. If you do frequent deploys, as most companies do, you can end up with dozens, perhaps hundreds of editions. We began to have major instability after hitting about 10 editions. I believe it was inter-edition dependencies that caused this, and so I began to instantiate every object in a child edition before switching to that as the default edition. Once I did that, the database regained the code stability we had before using editions. One problem solved!
The way to instantiate the objects into a child edition is to compile all the objects that are being referenced from earlier editions. If you switch into the child edition and run this SQL, it will generate all the DDL needed to make the edition stable.
SELECT decode(object_type,’PACKAGE BODY’,’alter package ‘||owner||’.’||object_name||’ compile body;’,
‘alter ‘||object_type||’ ‘||owner||’.’||object_name||’ compile;’)||’ –‘||edition_name cmd
FROM dba_objects o WHERE edition_name <> sys_context(‘USERENV’, ‘CURRENT_EDITION_NAME’);
The only problem with this approach is that you just doubled the number of editioned objects in your database, by adding a single child edition. That also will not scale well. It’s like adding new shingles on top of the old ones on your roof. You can do that once or twice, but if you do it a hundred times . . .
The solution will be in my next post . . .