This discussion is archived
1 2 Previous Next 18 Replies Latest reply: Jun 22, 2013 2:50 PM by AndyH RSS

Running multiple versions of Apex in a single database

BillyVerreynne Oracle ACE
Currently Being Moderated

The primary reason for only being able to run a single Apex version in a database, as I understand, is scope.

 

The Apex based URLs do not specify schema scope. For example, the f?p=.. URL refers to f as the procedure call to make. The schema owner is not specified. Oracle scope resolution is used to resolve that f to the actual procedure to call - using public synonyms.

 

As a public synonym can obviously only resolve to a single object, it means (when using public synonyms for scope resolution) only a single Apex version can be referenced.

 

However, local scope resolution precedes public scope. If the mod_plsql DAD refers to schema FOO, and schema FOO has a complete set of synonyms to resolve calls to another Apex schema (different version),  it should work. Right?

 

Anyone ever tried it? Has this been raised and discussed before? (could not find anything much on this approach in my googling).

 

Why? Only being able to run a single Apex version is very problematic. You cannot deploy new version to development only, as that means you are now unable to deploy Apex apps to production running an older Apex version. You cannot deploy an Apex upgrade to both dev and prod at the same time as management deems it a risk and first want existing apps migrated and tested on dev first... which means an inability from the time upgrading dev, to deploy any Apex app fixes to prod until prod is also upgraded. A fugly catch 22.

 

Would a separate DAD, dedicated schema, local synonyms for different Apex version in that schema, work? Am planning to try it, but if this is already known as a failed approach, I would prefer not to waste my time in vain.

 

Thanks.

  • 1. Re: Running multiple versions of Apex in a single database
    Christian Neumueller Expert
    Currently Being Moderated

    Hi Billy,

     

    private synonyms for the DAD schema and your workspace schemas would solve the scope issue, as you mentioned. The APEX schemas have version names (e.g. APEX_040100 and APEX_040200) and can live next to each other. However, we also reference uploaded files in the unversioned FLOWS_FILES schema and rely on a handful of objects in SYS. Especially the SYS objects can change between versions. We internally discussed how to solve these issues, but there are no plans to implement such a separation, currently. I understand the problem, but there is no direct technical solution yet, sorry. If you have DEV / TEST / PROD, maybe upgrading TEST first and getting it approved is your best option.

     

    Btw, I think this is a good candidate for a feature request: https://apex.oracle.com/vote

     

    Regards,
    Christian

  • 2. Re: Running multiple versions of Apex in a single database
    BillyVerreynne Oracle ACE
    Currently Being Moderated

    Thanks Christian. Much appreciated. Will give it a try (have a local Oracle Linux/RDBMS VM I can abuse on my desktop).

     

     

    PS. have update an existing feature request for this with my comments - thanks

  • 3. Re: Running multiple versions of Apex in a single database
    Christian Neumueller Expert
    Currently Being Moderated

    Hi again,

     

    I think my response above was not clear, APEX itself installs objects in SYS. The main problem is sys.wwv_dbms_sql. We ship different versions of that package with each version.

     

    Regards,

    Christian

  • 4. Re: Running multiple versions of Apex in a single database
    Vite DBA Pro
    Currently Being Moderated

    Hi Billy,

     

    Apparently this restriction will be fixed in an around about way when Oracle 12 is released. I can't remember where I read it but with the plug-able database feature of 21c, you will be able to install Apex in two ways. One in the base instance, where it will be accessible from all plugged in databases and in any plugged in database accessible only from that plug in. I don't know if both configurations are compatible.

     

    Regards

    Andre

     

    PS

    found this

    http://dgielis.blogspot.co.uk/2013/05/oracle-database-12c-and-apex.html

     

    Message was edited by: ViteDBA

  • 5. Re: Running multiple versions of Apex in a single database
    InoL Guru
    Currently Being Moderated

    >with the plug-able database feature of 21c

    Wow, do we really have to wait that long?

  • 6. Re: Running multiple versions of Apex in a single database
    Vite DBA Pro
    Currently Being Moderated

    InoL wrote:

     

    >with the plug-able database feature of 21c

    Wow, do we really have to wait that long?

     

    Dyslexia strikes again! (or too many red wines)

     

    Oracle do have a long release cycle

     

    Andre

  • 7. Re: Running multiple versions of Apex in a single database
    BillyVerreynne Oracle ACE
    Currently Being Moderated

    ChristianNeumueller wrote:

     

    I think my response above was not clear, APEX itself installs objects in SYS. The main problem is sys.wwv_dbms_sql. We ship different versions of that package with each version.

    Thanks Christian,

     

    But we can wrap (logically) two versions of the same SYS interface (package) if the interface header is not wrapped (code wise). And look at the call stack at runtime to decide which one of the two versions to invoke. Granted, an ugly hack perhaps. But one can make Oracle do some interesting things...

  • 8. Re: Running multiple versions of Apex in a single database
    Hari_639 Guru
    Currently Being Moderated

    Hello,

     

    It's always good idea to have 3 environments minimum for your APEX Applications.

     

    • DEV - Developers Area
    • TEST - For UAT. You can also use it for quick bug fixing when some major developments are in progress in DEV also when some Software Updates are in progress DEV etc.
    • PROD - To host Production Applications

     

    If you had 3 environments, then you won't need two APEX instances running parallel in same DB Good reason to push your management for new TEST environment.

     

    Regards,

    Hari

  • 9. Re: Running multiple versions of Apex in a single database
    Christian Neumueller Expert
    Currently Being Moderated

    Hi Billy,

     

    this could work if you put the different version's wwv_dbms_sql in separate schemas and provide a wrapper package in sys. It's a hack and an interesting experiment, but entirely unsupported, of course. I'm sure people have been threatened with lead pipes for smaller sins than implementing something like that on a production server ;-)

     

    Regards,

    Christian

  • 10. Re: Running multiple versions of Apex in a single database
    BillyVerreynne Oracle ACE
    Currently Being Moderated

    Not that simple. The issue is that when either DEV or TEST/UTA environments is  upgraded you cannot deploy to the next (non upgraded) environment. E.g. if only DEV is upgraded, you cannot deploy to TEST (or directly to PROD). If TEST is updated you cannot deploy to PROD. Etc.

     

    So a separate environment is needed only for upgrade testing. So DEV, TEST and PROD remains unchanged. A separate R&D environment is needed. R&D is upgraded to the new Apex version.

     

    But how do you test on R&D if you do not have a copy of Apex apps and their schemasa on DEV? So you need to duplicate DEV as R&D in order to do the upgrade and test. And when R&D testing pass, you need to update DEV, TEST and PROD all at the same time in order to be able to deploy from one to another.

     

    What's more, when you DEV environment is a multi TB 11 node RAC running a multitude of different system/app developments, all using Apex applications, how do you effectively create an interim R&D environment for duplicating DEV, in order to test an Apex upgrade? In this case, it is not simply grabbing a spare server and making it R&D - as it simply does not have the resources for providing a means to test all Apex apps in DEV.

     

    The ideal features would be:

     

    1. being able to run multiple Apex versions at the same time

    2. alternatively, being able to upgrade Apex versionA to versionB, indicate that all versionA apps need to run in compatabillity mode in versionB and not be migrated to versionB - allowing you to still maintain these apps as versionA and still deploy these as versionA apps, despite being on versionB

     

    Option 1 is do-able in my view. Option 2 would be quite complex (providing backwards compatibility deployment options for old version Apex apps).

  • 11. Re: Running multiple versions of Apex in a single database
    AndyH Journeyer
    Currently Being Moderated

    Hari_639 wrote:

     

    Hello,

     

    It's always good idea to have 3 environments minimum for your APEX Applications.

     

    • DEV - Developers Area
    • TEST - For UAT. You can also use it for quick bug fixing when some major developments are in progress in DEV also when some Software Updates are in progress DEV etc.
    • PROD - To host Production Applications

     

    If you had 3 environments, then you won't need two APEX instances running parallel in same DB Good reason to push your management for new TEST environment.

     

    Regards,

    Hari

    But you are addressing a slightly different issue there.

     

    Consider the case where you have a deployed APEX released in version 3.1 and want to upgrade to 4.2 - you are not changing your underlying application. At the moment you have to install (and pay for) a new DEV database to run the new version of APEX and a new TEST/UAT database as you need to continue to support the old/production version and regression test the new version of APEX.

     

    It would be nice to support multiple versions of APEX on one instance - you could then have the 3.1 and 4.2 environments running in parallel. I could then support customer A who has *my* application version 1 running against APEX 3.1 and support customer B who has *my* application version 1 running against APEX 4.2 and support customer C who is running *my* application version 2 against APEX 4.2, etc...

  • 12. Re: Running multiple versions of Apex in a single database
    BillyVerreynne Oracle ACE
    Currently Being Moderated

    ChristianNeumueller wrote:

     

    this could work if you put the different version's wwv_dbms_sql in separate schemas and provide a wrapper package in sys.

    Yep.

     

    It's a hack and an interesting experiment, but entirely unsupported, of course.

    The stress on interesting. As this type of hacking alway is...

     

    I'm sure people have been threatened with lead pipes for smaller sins than implementing something like that on a production server ;-)

    Goes without saying. But I only need to get the hack to work on a dev environment (not licensed as this is pure dev, and thus unsupported and all that).

     

     

    It would be a fun thing to try. Okay, so my definition of fun (which includes adding new "native" data types to PL/SQL's language definition) is perhaps unusual, if not downright weird. But I need some fun after sitting and debugging ODBC drivers on Linux the whole day...

  • 13. Re: Running multiple versions of Apex in a single database
    BillyVerreynne Oracle ACE
    Currently Being Moderated

    AndyH wrote:

     

    At the moment you have to install (and pay for) a new DEV database to run the new version of APEX and a new TEST/UAT database as you need to continue to support the old/production version and regression test the new version of APEX.

     

    Andy, a small correction. One should not have to pay for a dev environment s/w wise (running Oracle s/w products).

     

    The bluh at http://www.oracle.com/technetwork/indexes/downloads/index.html says:

    All software downloads are free, and most come with a Developer License that allows you to use full versions of the products at no charge while developing and prototyping your applications, or for strictly self-educational purposes

  • 14. Re: Running multiple versions of Apex in a single database
    Hari_639 Guru
    Currently Being Moderated

    I agree. "Being able to run multiple Apex versions at the same time" is definitely a good option. However I'm not sure if it's technically feasible.

     

    Few years back we have upgraded our APEX applications from 3.2 to 4.0. We had 3 environments DEV, TEST and PROD, where all applications and DB schema are exactly same.

     

    • First we have upgraded DEV APEX version to 4.0 and we have tested all our applications. This can take more time depending on number of applications, complexity etc, so during this time, we have used TEST environment for any bug fixing. However we had to bug fixing in both TEST and DEV.
    • Once we make sure that everything is fine in DEV, then we have upgraded our TEST APEX version and we have imported all applications from DEV to TEST (with any modifications that we have done to fix version compatible issues + bug fixes). And again we have quickly tested all the applications. This should not take more time as everything is tested in DEV.
    • And finally we have upgraded Prod and imported all applications from TEST to PROD.

     

    Regards,

    Hari

1 2 Previous Next

Legend

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