Skip to Main Content
Feature Request FR-3270
Product Area Application Builder
Status CLOSED

5 Voters

automatic generation of supporting objects

michael.weinberger 2 Public · Jul 14 2023

Idea Summary
A more automatic way to generate supporting objects. 
Apex is already able to generate create scripts for objects used by an application. But you have to select them manually.
It would be great if all objects (i.e. Tables, views, packages, etc..) used directly in the Apex app would be preselected, or better if the script would be automatically generated. One could always edit them later on.

Corresponding “drop scripts” for deinstallation could be autogenerated too.

Use Case
In development there are often extra tables, packages, etc that were once needed, but are no longer necessary for the application. Sorting them out before packaging can be quite some task.

Preferred Solution (Optional)
something like:
with (select object_name from user_objects where object_type in ('VIEW','TABLE', ….) my_objects
select my_objects.object_name from my_objects, APEX_APPLICATION_PAGE_REGIONS
where instr(region_source, object_name ) > 0

We reviewed this idea carefully, and while it was interesting, we concluded that due to all the internal implications we need to take into account, it is unlikely to make its way into APEX.

Known Duplicates

Known duplicates

FR-3977
FR-3977 Generate upgrade script on supporting objects from database
FR-4018
FR-4018 Export application with relative objects

Comments

Comments

  • jayson hanes Admin OP 2.4 years ago

    this would be great but will forever be complicated by custom SQL and PL/SQL everywhere in an APEX application..

  • michael.weinberger 2 OP 2.4 years ago

    Dear @jayson hanes , I do not think this would be so complicated. Let me explain:

    1. all sourcecode of an Apex application is stored in a handful of tables. As clobs.
    2. all existing objects are already known by the data dictionary. They can easily be queried.
    3. what must be done is to narrow down this list: we do not need all existing objects, but all objects in use.

    It should be easily possible to
    a) get a list of all objects
    b) search for the names of this objects somewhere in the Apex sourcecode (i.e. the clobs)
    if the name of the object is not found then it will be removed from the list.       

    c) Generate ddl for the remaining objects on the list.

    There is no need to interpret the sql or plsql of the application. You just have to find the names once in the code.

  • jayson hanes Admin OP 2.4 years ago

    APEX has been around for 20 years.. If this was so easily achieved and valuable, it would have been done by now :)

  • michael.weinberger 2 OP 2.4 years ago

    Of cource, objects referenced only in PL/SQL packages (or functions/procedures) or in object types must still be included manually. 

    But it will be a huge step forward

  • michael.weinberger 2 OP 2.4 years ago

    Supporting objects are a relative new feature of Apex, being around only a few years at most. And it seemed to me that it is still under development.
    Would you like me to improvise a script?

  • jayson hanes Admin OP 2.4 years ago

    I seem to recall supporting objects being around back when I started with it in APEX 3.0..  which was almost 2 decades ago.

    You have to understand that if this were implemented as you suggest it wouldn't be 100%, and when things aren't perfect, they cause more support challenges.

    This is why it is left up to the developer. I do understand that it would be nice if this was more easily achieved.

  • jose.albarran OP 1.3 years ago

    Hi, 

    I have just keep a talk about this with my Spanish colleagues. Before coming to Oracle, I was been a senior manager for projects with multiple technologies. The auto generation of DDLs, and the generation of initial and upgrade/downgrade scripts has been there for a long, long, long time for all ORMs. I have used this with PHP/Laravel/Eloquent, Python SQLAlchemy, Java Spring (with comments), C# EntityFramework and Java with Android Studio.