This content has been marked as final. Show 7 replies
Does it mean everyone uses single workspace for production and development?
Nope. We have 4 different workspaces (Dev, Test, Acc, Prod).
We (almost) always move the whole application from one stage to the next. (Now and then it's just one page )
The export sql-files are stored in source control.
So there is nor real "merge" : it is overwrite
BTW: Dietmar Aust wrote an excellent chapter on this subject (Lifecycle Management) in the Expert Oracle APEX book...
We (*almost*) always move the whole applicationHow does your script choose which parts of application must not be moved? How do you compare dev/test workspaces? Exported application sql is illegible so it isn't trivial to understand what was changed having svn diff only.
I thought apex stores data in APEX$xxx tables but they are empty while my app is pretty rich. Oracle SQL Developer has "Application Express" object list which contains human readable application tokens (pages,regions,items etc.) but there isn't all data here, for example LOV and lists don't have source sql code. Looks like oracle db has special section for apex tokens.
This makes an Apex application somewhat unfriendly to version control systems, even at the application export level as exports files will vary in line level descriptions even though the application is the essentially same. Note though that the base database objects can be stored quite easily in VCS as DDL scripts and PL/SQL scripts.
Until the Apex team come up with something better, I would advise that you store database code objects, SQL DDL, in VCS as individual objects. From a VCS point of view, Apex applications are best stored as one single object and moved as such between environments. This may change in the future from the Apex team, but nothing I've seen is leading in that direction. Note also at the Apex builder level there is also the ability to lock individual pages to prevent unwanted changes to pages by other developers. Another recommendation would be to centralise as much PL/SQL code into the database as possible, and the only PL/SQL code in the Apex application is just procedural calls.
Hope this helps.
My colleague raised this a little while ago - support the cause!
It is funny but only 6 of 351 (~2%) requests have been resolved on Oracle Application Express Feature Requests =)
It's a nice idea but the implementation is rather flawed.
Also, there doesn't seem to have been that much feedback from the APEX team...