Change is coming...and no, I'm not referring to the forthcoming change in Washington. I'm referring to Oracle Application Express.
Since the first supported release of Application Express (Oracle HTML DB 1.5), Application Express has been delivered as a supported feature of the Oracle Database, supporting database releases 9.2.0.3 and higher. So even though Oracle HTML DB 1.5 was delivered as a feature of the Oracle Database Release 10gR1, a customer could actually download it from the Oracle Technology Network, install it in their Oracle Database 9iR2 9.2.0.3, and be in a supported configuration.
For the forthcoming release of Oracle Application Express 3.2, which introduces Oracle Forms Conversion, the minimum database version will continue to be 9.2.0.3. But for Oracle Application Express 4.0, the minimum database version will be Oracle Database 10gR2 10.2.0.x - possibly even 10.2.0.4.
Turning customers into rockstars, with Oracle Database, SQL and Oracle APEX.
11 comments:
And here I thought you were talking about HEROES ....
IT'S COMING....
I think that's a safe and nice step to move to 10g as minimum database release requirement...
Congrats to APEX team for their excelent job!
Regards
Joao
Does this mean that we might see an update to the Oracle XE product with the release of 4.0?
Hi Joel,
is that just a "strategic" decision or is it motivated by some technical reason like an extensive use of functions available only in 10GR2?
Cheers,
Flavio
I'm hoping that we'll see use of DBMS_UTILITY.FORMAT_ERROR_BACKTRACE in the error handling.
Because exceptions are trapped in PL/SQL (since that's "all" Apex is), without that it has been hard to track down where the error is occurring.
Hi Joel,
maybe it would be a good idea to put up a forum pull to the news of APEX 4.0 and the minimum database requirements. Could be good to know what whole the community things about it.
In my case I can just hope that a new version of the XE database will come out before. :D
Regards,
Tobias
@Tobias: You mean this blog doesn't reach the whole APEX community? :) You're right, that's a good suggestion about putting this on the forum.
@Flavio: It is a strategic decision. Over the years, I have been compiling a list of 10.x-specific things I'd like to be able to exploit in the APEX engine, but could not because of this 9iR2-least common denominator. This ranges from linguistic sorting to use of REGEXP, and as Gary gives an example of - other functionality we can exploit.
As far as XE goes, the development of a new XE is independent of APEX 4.0, although I, as well, would like to see a new version of it in 2009.
Hi Joel,
do you think that creating a "modular" Apex that includes certain features depending on the setting of something like a build option would make the configuration of Apex unmanageable?
One of the features that i lately i've been thinking of would be to have a boolean approach to build options, allowing to specify more than one against each component.
For instance one could create a modularized application where certain pages are available if build options "10GR1" or "10GR2" are selected.
Kind regards,
Flavio
Hi Joel. Sorry if I ask a very basic question, but if I understand correctly, if the minimum release needed to support ApEx 4.0 would be 10.2.0.4 the Oracle XE will be not compatible? Is it rigth ? This is why some guys are asking a Oracle XE update ? Thanks a lot.
@Byte64 (Flavio),
I *think* I understand when you refer to a modular APEX - we already have that today. There are certain features which are enabled based upon your database version. And there are different files compiled based upon your database version. I would love to be able to use conditional compilation of PL/SQL (and ifdef-like construct), but that requires 9.2.0.7 or higher, and I'm pretty sure it doesn't work with wrapped PL/SQL.
If you don't use conditional compilation, then you can't use static compilation - you would have to dynamically execute the database-specific code you wanted, as a reference to a new-in-10.2 database PL/SQL package won't compile in a 9.2 database. And dynamic execution is sub-optimal (needs to be parsed every time, won't exploit ncomp, etc.).
Trust me - it's a problem that has to be carefully managed. And like I said - I would love to exploit functionality which we cannot do today.
Think about this - probably by the time APEX 4.0 is released, there will be 10.2, 11.1 and 11.2. To add 9.2 and 10.1 to this mix, when very few customers are actually using these database versions with APEX, isn't worth the real and opportunity costs.
Joel
Joel,
alternatively you might consider the possibility of designing real modules, sort of plug-ins that can be added directly by the user.
That would require the usual conditional installation, just like any apex application that performs validations prior to install itself and if the database version is not compatible, it stops the process.
So, instead of doing everything automatically, you might let the user take the decision whether he/she wants to have a certain functionality or not, but i do understand your point and i believe that moving to 10GR2 makes sense from a commercial point of view as long as you retain compatibility with XE until a newer version of XE is released.
By the way, allowing developers to extend Apex itself might be the next "frontier" for Apex. I am particularly keen at developing this kind of stuff (that's what I've been doing on almost each platform I've been working on in the last 25 years...), because in a certain sense it would "free" the Apex team from the responsibility of developing each and every new feature requested by the users.
But, clearly it's not a trivial task.
Flavio
Post a Comment