3 Replies Latest reply on Aug 12, 2018 3:17 PM by Mike Kutz

    Python vs. APEX




      Wonder if this is a silly question:  I'm thinking what the difference is between Python and APEX. Based on that we have Oracle Enterprise 11g, both these are free.  Then not considering learning curve, under what kind of situation/scenario, we should choose one of them as the tool to plot the data?   Thanks.

        • 1. Re: Python vs. APEX
          Adrian Png

          You're comparing apples with oranges here. If you're looking at building enterprise-ready web applications, then both would get you there. Difference is, APEX will get you there much faster. It has more charting abilities now with Oracle JET Charts. To help you get a sense of what's possible with these charts, the APEX development team provides a Packaged Application (Sample Charts) that illustrates its capabilities. For your convenience, I have staged one for you to have a quick look: https://apex.oracle.com/pls/apex/f?p=11681  (username: demo, password: demo).


          Considering how much Python is used for data analytics and visualization, there certainly would be plentiful of choices out there. That said, I have worked with people who have claimed that they could plot better charts with Python, and then we found a workaround to get those same data visualizations in APEX (keep a look out, I just might blog about that experience). There are web frameworks like Flask and Django out there to help you build a functioning web application, but they do come with learning costs, unless of course, you're already an acommplished Python programmer.


          Figure out what you need to solve first and weigh what's important to your organization. Both are great platforms, but you'll need to figure out which has the necessary attributes to get you to where you need to be with minimal cost in time and resources. Good luck!

          • 2. Re: Python vs. APEX

            Hi Jian


            I agree with Adrian. You are comparing Apples with Oranges!


            Puthon is a full-fledged powerful programming and scripting language. APEX is a rapid application development framework.


            You could compare for example Python vs Java. It is clearly a coding Battle or debate.



            However, as APEX developer, you are a PL/SQL Developer. That’s why if you would like to learn Python quickly, I would recommend the following tutorials

            Introduction to Python for PL/SQL Developers - Full Series


            I hope that helps




            1 person found this helpful
            • 3. Re: Python vs. APEX
              Mike Kutz

              I'm expanding "graphs generated by python" to "graphs generated by 3rd party graphing tools like SAS, JMP, GraphPad, Mathematica, MatLAB, GNU Plot, java, python, etc."


              Integrating with the Database

              In this scenario, the "final data" is sent to the 3rd party tool via REST (or SOAP).  The result is an image that is stored in the database.  APEX recalls that image.


              Being an Image, you can't ZOOM or change the scale.  You have no Filtering capability; you must look at all the data each time.  Adding "click on data point" feature was more of a PITA than what it was worth.


              On the other hand, the images were of such high quality, they were really good for thumbnails in IR and for custom PDFs.  (xslt-1.0 didn't support the graph types we needed)


              I recommend this technique when you need high quality graphs, the graph needs to be identical across multiple applications (including Report applications like BI Publisher/Apache FOP), and the data is expected to be static  (eg Results of science experiments for a PDF).


              note - If the 3rd party graphing tool does not natively support REST/SOAP calls to generate the images, your team will need to have the skill to create and maintain that Service.


              Integrate with APEX

              I tried this method prior to migrating the application to APEX.


              A Dynamic Action calls the REST service (see above) to regenerate the Image.

              Maintaining the code that translated "x,y on graph to x,y data points" was painful.


              On the other hand, if you need the graph to update based on filtered data, this can be useful.


              I recommend this technique when you don't need to click on the graph to do something AND the graph type is not available in APEX.


              note - If the 3rd party graphing tool does not natively support REST/SOAP calls to generate the images, your team will need to have the skill to create and maintain that Service.


              Using APEX Graphs

              APEX Graphs are generated by JavaScript on the Client.

              This allow for much better dynamically generated graphs than the other two scenarios.  Additionally, the "click on graph" code is maintained by not you.

              (I had to maintain control over how-often the REST call was made for Scenario 2.  Scenario 1 was controlled via Advance Queuing [AQ] )


              The downsides to this method are:

              • You can't transfer the resulting graph to a Print Server (BI Publisher/Apache FOP).
              • You are limited (out-of-the-box) to the types of graphs you can use.


              I recommend that you try to stick to this scenario as much as possible.  Your efforts to improve the graphing capabilities of APEX (including but not limited to Enhancement Requests) would be better off than the work needed to implement Scenario 1 or Scenario 2.


              APEX v18 would have made my usage of Scenario 2 completely useless.  (stay away from this method as much as possible)


              Scenario 1 is a must when you need to store the resulting graph as an image in the database.


              My $0.02



              1 person found this helpful