This is an index to a series of posts I have been writing about Edition-Based Redefinition.
New entries will be added as soon as they are published.
- Part 1: Overview and Setup [1-Dec-2017]
- Part 2: Locking, Blocking and ORA-04068 [5-Dec-2017]
- Part 3: Editions and Editioned Objects [15-Dec-2017]
- Part 4: Invalidation and Actualization of Dependent Objects [9-Jan-2018]
- Part 5: Explicit Actualization of Dependent Objects [12-Jan-2018]
- Part 6: Editionable and Non-Editionable, Editioned and Non-Editioned [29-Apr-2018]
- Part 7: Editioning Views [21-May-2018]
- Part 8: The Last Planned Downtime [23-May-2018]
- Part 9: Adding a New Column [25-May-2018]
- Part 10: Data Dictionary Views for Editioning Views [29-Jun-2018]
- Part 11: Database-Level Default Edition [18-Mar-2019]
- Part 12: Editions and Services [10-May-2019]
Very well written! Looking forward to the next part in the series. Thank you!
OMG!
Thank a lot for this BLOG!
BEST text about EBR.
Save you god autor)
Hmmm … So is the following a bug or a feature (how feature works):
Test case:
—————
Create test schema (TST):
-- Note! Run with DBA privileges
drop user tst cascade;
create user tst identified by tst;
alter user tst ENABLE EDITIONS;
alter user tst default tablespace users;
alter user tst quota unlimited on users;
grant create session, create table, create view, create sequence, create procedure, create type,
create trigger, create synonym, create any context, create job to tst;
create edition RELEASE_2024_1 as child of ORA$BASE;
create edition RELEASE_2024_2 as child of RELEASE_2024_1;
create edition RELEASE_2024_3 as child of RELEASE_2024_2;
create edition RELEASE_2024_4 as child of RELEASE_2024_3;
GRANT USE ON EDITION ORA$BASE to tst;
GRANT USE ON EDITION RELEASE_2024_1 TO tst;
GRANT USE ON EDITION RELEASE_2024_2 TO tst;
GRANT USE ON EDITION RELEASE_2024_3 TO tst;
GRANT USE ON EDITION RELEASE_2024_4 TO tst;
Then run the following test code (as user TST):
Note! The same behavor happens if packages (both spec and body) are created with ‘CREATE OR REPLACE EDITIONABLE PACKAGE …’.
alter session set edition=RELEASE_2024_1;
create or replace package foo as
procedure p1;
end;
/
create or replace package body foo as
procedure p1 as
begin
dbms_output.put_line('==> Ran P1');
end;
end;
/
alter session set edition=RELEASE_2024_2;
create or replace package foo as
procedure p1;
procedure p2;
end;
/
create or replace package body foo as
procedure p1 as
begin
dbms_output.put_line('==> Ran P1');
end;
procedure p2 as
begin
dbms_output.put_line('==> Ran P2');
end;
end;
/
All looks good, BUT …
—————————————
select object_name, object_type, status, edition_name
from user_objects_ae
where 1=1
and object_name='FOO'
and edition_name is not null order by 4;
OBJECT_NAME OBJECT_TYPE STATUS EDITION_NAME
--------------- -------------------- ---------- -------------------------
FOO PACKAGE VALID RELEASE_2024_1
FOO PACKAGE BODY VALID RELEASE_2024_1
FOO PACKAGE VALID RELEASE_2024_2
FOO PACKAGE BODY VALID RELEASE_2024_2
FOO PACKAGE BODY INVALID RELEASE_2024_3
alter session set edition=RELEASE_2024_3;
select text from user_source where name='FOO' and type = 'PACKAGE' order by line;
TEXT
------------------
package foo as
procedure p1;
procedure p2;
end;
select text from user_source where name='FOO' and type = 'PACKAGE BODY' order by line;
TEXT
-------------------------------------------
package body foo as
procedure p1 as
begin
dbms_output.put_line('==> Ran P1');
end;
end;
The specification seems to be inherited from RELEASE_2024_2, while the body seems to be inherited from RELEASE_2024_1.
Hi Lasse.
An important rule in EBR is that once an edition is created, you should not compile objects in any of the ancestor editions, only in the leaf edition.
Thanks,
Oren.