Logger 3.1.0: Released

We're pleased to annouce that Logger 3.1.0 is released! It is available for download from the release downloads page.

For more information about this release please read the post on Logger 3.1.0 Beta or view the change log.

If you have any feedback please submit on the project's issue page. If you want to see what we've got planned for the next release check out the feature list for Logger 3.2.0!

Logger 3.1.0: Custom Preferences

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 logger_prefs table.

They're two new API statments to handle custom preferences for Logger: logger.set_pref and 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 pref_type 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 3.1.0: Logger Level Best Practices

Logger's main procedures at:

  • logger.log
  • logger.info[rmation]
  • logger.warn[ing]
  • logger.error
  • logger.log_permanent

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 3.1.0: NO_OP Install Changes

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 3.1.0: log_apex_items Enhancements

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_logs_apex_items.

Previously logger.log_apex_items only had two parameters: p_text and 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.