Query Best Practice for Reports

Question

I am new to Apex and I am wondering what is the best practice for store your sql quries for reports.  I am a believer of storing all sql behind pacakge functions or procedures.  And it looks like the only options for report pages are to use a direct SQL query, or a function that returns a query as a string.  Yes the function method counts as putting the code in Oracle but not really.  It is still getting compiled and parsed on the Apex side.  It would be nice if Apex could handle a cursor but I have read that it doesn't directly. You have to have a function that returns a cursor and then create a pipelined function that calls the cursor function.  That is kind of silly.  Is there some other way to do this?
Apex 4.2
Oracle 11.2.0.2
Thanks for any input.
Jeff

Answer 1

Hi Jeff,
I'm not necessarily a believer in packaging queries. I'm a little more pragmatic in that I believe it may make sense in environments where you have a client environment that just expects a result set that is then manipulated by the client for the purposes of presentation, pagination etc. Apex has a different architecture in that the client is purely an HTML presentation layer (browser) and the presentation, pagination etc is formulated in the database along with the data using the Oracle web toolkit, which is a set of internal packages that produce HTML. Note that handling and manipulating ref cursors inside PL/SQL is not a joy, they were mainly designed to be passed out to external clients. (Often to shield programmers who don't or won't even try to understand relational concepts)
This means that when you create a report based on a query, the Apex engine will manipulate that base query, depending on the display requirements and pagination requirements of your report, before it submits that query to the database for execution. To get an idea of how this manipulation occurs, you can run your report in debug mode and check the actual query that is submitted to the database. If the query is presented as an already executed ref cursor, then the Apex engine can't execute in the way that it does. As you have already found out, the only way of using packaged queries returning ref cursors is by the use of a pipelined function, so that the Apex engine can treat the result as a normal query.
This is the architecture of Apex, and I suspect that re-engineering the Apex engine to handle ref cursors natively, as opposed to using a pipelining trick, would be a considerable change. I hope this at least helps to explain why ref cursors and Apex don't mix. I personally don't see the purpose of having an abstraction layer of packaged queries below an abstraction layer of an API such as Apex. SQL is a perfectly good API.
Regards
Andre