This discussion is archived
3 Replies Latest reply: Feb 5, 2013 3:30 PM by rp0428 RSS

editions based redefinitions to replace individual schema  objects concept

905340 Newbie
Currently Being Moderated
Hello,
Just wanted to get some opinion.
Oracle db : 11.2.0.2
Our company has only one schema where all objects reside in the design database and developers add code, modify objects etc within that same schema and invalidate other code and other developers sometimes spend a lot of hours around this.
We personally thought to use editions based redefinitions to resolve this , that way, each developer could modify code in his own edition and other developers are unaware of the change and unaffected.
Would this be ok and if we go this route, how does this affect the current tablespace and what other issues could we expect.
Lets say we re talking 10 developers.
Thanks.
  • 1. Re: editions based redefinitions to replace individual schema  objects concept
    rp0428 Guru
    Currently Being Moderated
    And how, exactly, will you handle changes to tables since tables are not editionable?

    Your approach is far too simplistic and not realistic.
    >
    Our company has only one schema where all objects reside in the design database and developers add code, modify objects etc within that same schema and invalidate other code and other developers sometimes spend a lot of hours around this.
    >
    There should be a schema for each developer.

    Each of those developers can easilyl create their own code and test objects in their own schema without conflicting with each other at all.

    They won't invalidate each other's code since there will only be one OFFICIAL code version and that will be in the app schema.

    See this Oracle white paper on this topic.
    http://www.oracle.com/technetwork/database/features/availability/edition-based-redefinition-1-133045.pdf
  • 2. Re: editions based redefinitions to replace individual schema  objects concept
    905340 Newbie
    Currently Being Moderated
    Thanks for your reply.
    The problem is even if we have private objects in our own schema, those would not be referenced since developers login to the app using the main schema bcos of object access restrictions and other thing is most of the code references objects using main schemaname.object (old code) and not much synonyms.
  • 3. Re: editions based redefinitions to replace individual schema  objects concept
    rp0428 Guru
    Currently Being Moderated
    >
    The problem is even if we have private objects in our own schema, those would not be referenced since developers login to the app using the main schema bcos of object access restrictions and other thing is most of the code references objects using main schemaname.object (old code) and not much synonyms.
    >
    I understand that but edition-based redefinitioning is primarily to support 'code' updates, not DDL and object updates. And it is primarily used to support those updates in the higher-level environments even including production. For those environments it isn't really necessary to have editioned tables or the other currently non-supported objects; the goal is to get new code into place while the current code is running and then 'switch' to it as seamlessly as possible.

    The white paper I cited lists the limited objects that can be editioned.
    >
    editionable object types, editions-enabled users, and editioned objects
    • Views (and therefore editioning views), synonyms, and all the kinds of PL/SQL objects
    type13 (and therefore crossedition triggers) are editionable object types. There are no other
    editionable object types. For example, table is not an editionable object type; nor is
    java class14.
    >
    Unfortunately, for DEV environments those restrictions are generally too onerous when entirely new features are being added.

    A few of the larger environments I've worked in the developers essentially needed their own local version of the entire chain of browser, web server, app server and database. Functionality such as single-signon was global but that was about it.

    Because of the limitations and the relatively steep learning curve to properly architect and implement editioning you need to do adequate preparation and testing to make sure it is going to help you more than hurt you.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points