Strange behavior with EBR II

This is an update on the previous article “Strange behavior with EBR“.
To try to understand a little more I have tested some more. The result suggest that what’s inherited in my latest edition is actually not what I first thought (read last article). Let’s have a look.

I’m using the same TST schema as created in the previous article.

To be able to delete the editions which I’m testing with I create some new editions (with no existing objects). The following is ran as a user with DBA privileges:

-- -----------------------------------------------------------------------
-- Note! Before dropping an edition the TST user must switch to some other 
-- edition first. For instance RELEASE_2024_3
-- Run as TST: alter session set edition=RELEASE_2024_3;
-- -----------------------------------------------------------------------

-- drop edition RELEASE_2024_6 cascade; -- Uncomment if need for new tests
-- drop edition RELEASE_2024_5 cascade; -- Uncomment if need for new tests
-- drop edition RELEASE_2024_4 cascade; -- Uncomment if need for new tests
create edition RELEASE_2024_4 as child of RELEASE_2024_3;
create edition RELEASE_2024_5 as child of RELEASE_2024_4;
create edition RELEASE_2024_6 as child of RELEASE_2024_5;
GRANT USE ON EDITION RELEASE_2024_4 TO tst;
GRANT USE ON EDITION RELEASE_2024_5 TO tst;
GRANT USE ON EDITION RELEASE_2024_6 TO tst;

Then I create the first version of my FOO package (spec and body) as the TST user:

alter session set edition=RELEASE_2024_4;
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;
/

Everything looks fine yet.

SQL> col object_name for a10
SQL> col edition_name for a15
SQL> select object_name, object_type, status, edition_name 
  2  from user_objects_ae e
  3  where 1=1
  4    and object_name='FOO'
  5    and edition_name is not null order by 4;

OBJECT_NAM OBJECT_TYPE             STATUS  EDITION_NAME   
---------- ----------------------- ------- ---------------
FOO        PACKAGE                 VALID   RELEASE_2024_4 
FOO        PACKAGE BODY            VALID   RELEASE_2024_4

Then I switch to edition RELEASE_2024_5, and first recreate the package body with a minor change (just to be able to verify that this is the edition 5 version:

SQL> alter session set edition=RELEASE_2024_5;

Session altered.

SQL> create or replace package body foo as
  2    procedure p1 as
  3    begin
  4      dbms_output.put_line('==> Ran P1 - RELEASE 5');
  5    end;
  6  end;
  7  /

Package Body FOO compiled

When I now check the USER_OBJECTS_AE everything still looks OK (Valid).

SQL> col object_name for a10
SQL> col edition_name for a15
SQL> select object_name, object_type, status, edition_name
  2  from user_objects_ae e
  3  where 1=1
  4    and object_name='FOO'
  5    and edition_name is not null order by 4;

OBJECT_NAM OBJECT_TYPE             STATUS  EDITION_NAME   
---------- ----------------------- ------- ---------------
FOO        PACKAGE                 VALID   RELEASE_2024_4 
FOO        PACKAGE BODY            VALID   RELEASE_2024_4 
FOO        PACKAGE BODY            VALID   RELEASE_2024_5

Now I introduce the new version of the specification – still in RELEASE_2024_5:

SQL> alter session set edition=RELEASE_2024_5;

Session altered.

SQL> create or replace package foo as
  2    procedure p1;
  3    procedure p2;
  4  end;
  5  /

Package FOO compiled

Now the PACKAGE BODY in edition 5 (RELEASE_2024_5) becomes INVALID (as expected).
Note! See query against USER_OBJECTS_AE above.

OBJECT_NAM OBJECT_TYPE             STATUS  EDITION_NAME   
---------- ----------------------- ------- ---------------
FOO        PACKAGE                 VALID   RELEASE_2024_4 
FOO        PACKAGE BODY            VALID   RELEASE_2024_4 
FOO        PACKAGE                 VALID   RELEASE_2024_5 
FOO        PACKAGE BODY            INVALID RELEASE_2024_5

So then we also recreate the PACKAGE BODY in edition 5.

SQL> alter session set edition=RELEASE_2024_5;

Session altered.

SQL> create or replace package body foo as
  2    procedure p1 as
  3    begin
  4      dbms_output.put_line('==> Ran P1');
  5    end;
  6 
  7    procedure p2 as
  8    begin
  9      dbms_output.put_line('==> Ran P2');
 10    end;
 11  end;
 12  /

Package Body FOO compiled

Now the package body becomes VALID in edition RELEASE_2024_5, but INVALID in edition RELEASE_2024_6. Seems a little strange (but as we also noticed in the previous blog post).
Note! See query against USER_OBJECTS_AE above.

OBJECT_NAM OBJECT_TYPE             STATUS  EDITION_NAME   
---------- ----------------------- ------- ---------------
FOO        PACKAGE                 VALID   RELEASE_2024_4 
FOO        PACKAGE BODY            VALID   RELEASE_2024_4 
FOO        PACKAGE                 VALID   RELEASE_2024_5 
FOO        PACKAGE BODY            VALID   RELEASE_2024_5 
FOO        PACKAGE BODY            INVALID RELEASE_2024_6

So now let’s look at the USER_SOURCE in edition RELEASE_2024_6.

SQL> alter session set edition=RELEASE_2024_6;

Session altered.

SQL> 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 - RELEASE 5');
   end;

end;

7 rows selected.

So … the next edition has not inherited from edition RELEASE_2024_4 (as we thought in the previous blog post), but rather inherited the previous version of the package body in RELEASE_2024_5.
Still very strange??? Or is this expected behavior???

What if I delete only edition RELEASE_2024_6, and then recreate it:

-- RAN as DBA (after switching TST back to an earlier edition)
SQL> drop edition RELEASE_2024_6 cascade;

Edition RELEASE_2024_6 dropped.

SQL> create edition RELEASE_2024_6 as child of RELEASE_2024_5;

Edition RELEASE_2024_6 created.

SQL> GRANT USE ON EDITION RELEASE_2024_6 TO tst;

Grant succeeded.

If I now check USER_OBJECTS_AE, everything looks fine again. But it’s shouldn’t be necessary.
Note! See query against USER_OBJECTS_AE above.

OBJECT_NAM OBJECT_TYPE             STATUS  EDITION_NAME   
---------- ----------------------- ------- --------------- 
FOO        PACKAGE                 VALID   RELEASE_2024_4 
FOO        PACKAGE BODY            VALID   RELEASE_2024_4 
FOO        PACKAGE                 VALID   RELEASE_2024_5 
FOO        PACKAGE BODY            VALID   RELEASE_2024_5

The last is not really surprising, but I expect the inheritance to work also with an existing edition.

Post a Comment

Your email is never published nor shared. Required fields are marked *