Just been to my favourite presentation so far at OpenWorld it was by Lucas Jellema and it was called:
Continuous Database Application Evolution with Oracle Database 11g Release 2
However it was really all about Edition Based Redefinition. Lucas brilliantly explained the concepts behind Editions, giving the metaphors of parallel universes, or seeing a new road being built alongside an existing one, and then one day you are switched over to the new road. Lucas also gave a series of demonstrations using these features to highlight how to use them.
Lucas made it seem really, really straightforward.
Objects identified by schema, object type, object name and now edition. Database sessions run in the context of a specific edition, using that editions specific collection of versions of objects.
A new edition inherits objects from the previous editon, except for those that are different in the new edition. You can run multiple editons or versions in the same database at once. So, with multiple front ends accessing the database, it’s easy to roll out new versions of an application, an updated application accesses the new edition inside the database while the as yet to be upgraded version still accesses the old edition.
The following objects are editionable:
One obviously missing piece is tables, and when I first heard a little snippet about editons, I thought that not having tables editionable was a real killer, but it turns out it’s not.
Any applications that you want to able to upgrade completely online should not use the base tables. You need to rename your base tables, and then create edtionable views on top of these base tables, these views must not contain join conditions. You can create triggers on top of these editionable views. Using editionable views on top of base tables has no performance impact.
Lucas also did a great job at explaining how cross-edtion triggers enabled underlying changes to the base table to take place while still allowing different editions to be live at the same time, this included both adding and deleting columns from the base table. Lucas was saying you should have your application set the edition it requires when connecting to the database.
This was a fantastic presentation but it’s such a shame the room was practically deserted, it had been a long day, but this presentation really deserved a much larger audience. I know I’ll be haranguing all my developers to go and get up-to-speed with Edition Based Redefinition.
jarneil 
Thanks for your kind words! But then again, it is a great story to be allowed to tell!
Best regards, Lucas
Hi Lucas,
Thanks for explaining to me what happens to a PL/SQL function used in a function based index!
jason.
Haranguing eh? We can always count on you for the subtle approach, Jason!
Editions sound great. But unfortunately step 1. “Rename your base tables, and then create edtionable views on top of these base tables” could be pretty painful…
Hi Chris,
Thanks for reading!
Yep there definitely is a one off hit that you can’t do online, you need to have the applications down for this. However, once you’ve done that your applications may never be unavailable again.
It may be worth the initial pain to have that continual application availability.
jason.
I suspect the devil is in the detail and you’ll find that adding and removing columns is easy, but there are lots of other things that don’t work so smoothly. Especially if the change involves both DDL and associated DML….
I have difficulty purging prior editions that clutter up my system: we deploy new code every 2 weeks, hence a new edition every time:
ORA$BASE –> v37 –> v38 for example.
I actualized all objects from ORA$BASE to v37, and for v38, same thing, actualized all v37 into v38
then i tried this:
DROP EDITION v37 cascade;
and no luck.. got this:
SQL Error: ORA-38810: Implementation restriction: cannot drop edition that has a parent and a child
Any words of wisdom?