We're pleased to annouce that Logger 3.1.0 is released! It is available for download from the release downloads page.
Logger stores its preferences in the
logger_prefs table. This table has always meant to be modified by either the Logger installation files or the API.
With the introduction of Plugins for Logger there may be a requirement for developers to store additional prefernces in the
They're two new API statments to handle custom preferences for Logger:
logger.del_pref. These two procedures, along with
logger.get_pref all take in a new parameter called
p_pref_type. The purpose of
p_pref_type is to be able to namespace preferences. The
LOGGER is reserved for system level preferences.
This new column will also help support for Logger Addons which is scheduled for next release. We'll blog more about this once the addon structure is finalized.
More information can be found the API docs.
Thanks to Alex Nuijten for providing the idea and the initial code.
Logger's main procedures at:
A common question most developers had when using Logger for the first time was "when should we use each procedure?". Now there is a break down of each procedure and their recommended use cases in the Best Practices Guide.
Special thanks to Dietmar Aust for suggesting that we create this guide.
Logger allows for a NO_OP installation which means that when installed in NO_OP mode all the calls to it will just run a null statement. This is typically used in production systems where, for various reasons, you may not want to actually run Logger. Note: this is not the recommended approach since running Logger in Error mode is better as it will still log.
The NO_OP installation only installed the package spec and body. This may have caused some errors as the package itself references the Logger tables. Code in applications calling logger may have also referenced the other Logger objects.
Starting in 3.1.0, the NO_OP installation will install all Logger objects so that code that worked in a development environemnt with the full version of Logger will still compile and run in a NO_OP version. It just won't log any information. To read more about the decisions around these changes please review Issue 78.
logger.log_apex_items is a procedure to store all the APEX items for a user's current session. When called, a parent entry is stored in the usual
logger_logs table and all the APEX items and thier values are stored in
logger.log_apex_items only had two parameters:
p_scope. These parameters are common with all the other main Logger procedures. Aside from the new
p_level parameter, it now takes in two additional parameters to give you more control of what is logged:
p_item_type: This determines which APEX items will actually be stored in
logger.log_apex_items. Valid values are:
logger.g_apex_item_type_all: For both application and page level items.
logger.g_apex_item_type_app: For application items only.
logger.g_apex_item_type_page: For page items only.
<page number>: Pass in a page number and only items on that page will be logged.
p_log_null_items: If set to true, items will still be logged even if their values are null. If set to false, only non null values will be logged.
Both of the new parameters help reduce the amount of APEX items that are logged. This can be very useful in large applications where you may only need to see a subset of all the items when debugging you application.