I've had the privilege of presenting at Oracle conferences before, but it's not an easy process to first get approved. I've been denied (many) more times than approved.
So in the spirit of sharing disappointments, I'll go first. This was a session proposal I submitted for the IOUG Collaborate conference:
TITLE
Beyond the Backtrace: Using UTL_CALL_STACK for Easy PL/SQL Instrumentation
ABSTRACT
There are several open source libraries available for PL/SQL developers to easily instrument their code inside Oracle Database. Frameworks like ILO, Logger, and BMC_DEBUG are robust and stable offerings to get developers started with instrumentation. A common drawback in these libraries is their requirement to support older versions of Oracle, and thus don't take advantage of the new (in Oracle 12.1) package UTL_CALL_STACK.
The UTL_CALL_STACK package provides access to the Oracle stack that PL/SQL developers had to previously come up with clever workarounds to gain access to. This new API allows developers to easily know exactly where they are and where they were in the call stack, thus providing a way to wrap instrumentation code with calls to DBMS_APPLICATION_INFO and DBMS_MONITOR or DBMS_SYSTEM if needed.
In this session Mikey Sanchez will review the advantages of and ways to implement PL/SQL instrumentation in Oracle Database. A simple framework for utilizing UTL_CALL_STACK will be presented to make instrumenting existing PL/SQL code easy. He will also provide tips on how to use the UTL_CALL_STACK package to provide more insights than simple backtraces during exceptions.
Top comments (2)
I wound up repurposing this into a blog post after AssertJS passed it up last year:
The Orchid, the Wasp, and the Test Fixture
Have you ever made a simple, innocent tweak to your API or database schema and realized you'd just rendered dozens or hundreds of barely-related testcases potentially inaccurate? Or worse, have you not realized it before moving on to something else, only to be rudely interrupted by a build failure or a defect report? Maybe you've put off or kludged around a structural change you knew would be far more trouble to test, both directly and indirectly, than it would be to implement. I've been in all three situations more often than I'd prefer to admit. But what can we actually do about it? And what on earth is a rhizome, anyway? Let's borrow from poststructuralist philosophy to rethink data fixtures in an organic, composable way that gives us a better handle on one of the messier aspects of backend testing.
Hey Dian,
Thanks for sharing your abstract. I'm really glad to hear that you were able to re-purpose this as an opportunity for a blog post!