pl/sql code instrumentation
- Thread starter Babo
- Start date
PL/SQL Developer does not include a library for logging functionality.
We use a custom instrumentation package where I work. It takes a fair amount of time to instrument a package even using templates.
What would be kind of cool, I think, is if PL/SQL developer had a way to automatically mark the package with instrumentation code using a tool. If it used templates and/or variables somehow, it could be flexible and it could mark up whenever a variable was assigned, when a procedure was entered/exited, the parameters and stuff. Perhaps have a few included templates for popular instrumentation packages like log4plsql and debugf, but still have the option to create our own. Variables used in the templates could include package name, procedure/function name, variable name etc.
What would be kind of cool, I think, is if PL/SQL developer had a way to automatically mark the package with instrumentation code using a tool. If it used templates and/or variables somehow, it could be flexible and it could mark up whenever a variable was assigned, when a procedure was entered/exited, the parameters and stuff. Perhaps have a few included templates for popular instrumentation packages like log4plsql and debugf, but still have the option to create our own. Variables used in the templates could include package name, procedure/function name, variable name etc.
Another option I thought of is if it could have an option to only do this when when compiling. Some like to have it instrumented in development instances, but not in production. If it made a copy of the code, instrumented it, and compiled that, the source code would still not be instrumented and could move on to production. (Kind of like a twist to the safe compile option).
I have added this to the list of enhancement requests.
Although log4plsql has been around a while and provides lots of output options, I found it overblown, and the last time I looked, not terribly well maintained.
The instrumentation features of the open source PL/SQL Starter Framework make it very easy to use and dynamic.
By easy to use, I mean it's no harder than taking your existing comments and wrapping them in a logs.dbg('message here') call. There are also the info(), warn(), and err() options, but I primarily use dbg().
The framework handles the rest (whether the output is ignored (debugging is toggled off), whether the output goes to file, the screen or a logging table, and all the metadata about the call, like which package, routine, line number, client identifier, IP address, etc.).
By dynamic, I mean what Mike was hoping for. It is table-driven. Although you can override it for unit tests, the debug output is toggled off by default. To turn it on, one simply alters a column value in the framework core schema, either turning debugging on entirely, or for a given session, or given user, or given PL/SQL unit or list of units. This is invaluable when a user kicks off a report, or backend process in production, then calls support asking why it's taking longer than normal.
Yes, I'm the author, but I've been doing this for 15 years now, and this is the easiest-to-use instrumentation I've ever worked with. The framework does take a little time to set up, but once that's invested, all your future apps can start benefiting from it.
The instrumentation features of the open source PL/SQL Starter Framework make it very easy to use and dynamic.
By easy to use, I mean it's no harder than taking your existing comments and wrapping them in a logs.dbg('message here') call. There are also the info(), warn(), and err() options, but I primarily use dbg().
The framework handles the rest (whether the output is ignored (debugging is toggled off), whether the output goes to file, the screen or a logging table, and all the metadata about the call, like which package, routine, line number, client identifier, IP address, etc.).
By dynamic, I mean what Mike was hoping for. It is table-driven. Although you can override it for unit tests, the debug output is toggled off by default. To turn it on, one simply alters a column value in the framework core schema, either turning debugging on entirely, or for a given session, or given user, or given PL/SQL unit or list of units. This is invaluable when a user kicks off a report, or backend process in production, then calls support asking why it's taking longer than normal.
Yes, I'm the author, but I've been doing this for 15 years now, and this is the easiest-to-use instrumentation I've ever worked with. The framework does take a little time to set up, but once that's invested, all your future apps can start benefiting from it.
No, this is not added in 9.0.
Similar threads
- Discussion
