Monday, April 15, 2013

Logger 2.0.0 Alpha

Logger is a PL/SQL logging and debugging framework. It's used in many organizations to instrument code in their Oracle applications. Tyler Muth created Logger a few years ago and has since released several upgrades, the last being 1.4.0.

I contacted Tyler a few months ago about the possibility of working together to upgrade Logger and expand on its capabilities. Since then we've been busy working on Logger on our spare time (which isn't much these days). That being said, I'm pleased to announce that Logger 2.0.0.a01 (Alpha) is now available to download!

Besides some underlying changes, such as moving to GitHub and a new build script, the following things were added to Logger:
  • Upgrade process: Can upgrade Logger rather than having to uninstall the old version and install the new version.
  • Log parameters: Standardize the logging of parameters when entering a procedure or function. You won't need to convert the data format as the procedure is overloaded to handle many different object types.
  • Logger level by Client Identifier: This is by far one of the features I think most people wanted in Logger. You can now set the logging level based on a Client Identifier.
  • Other: They're a few other features we may get into this 2.0.0 release. If not they will be added in future releases.
You can read more about the new features, along with demo snippets on Logger's new home page: https://github.com/tmuth/Logger---A-PL-SQL-Logging-Utility The new home page contains all the help text and sample code.

What next? Well we've been busy at work developing Logger now we're looking to the community to help test it out. Please download it, install or upgrade, and give it a try. If you find any issues please post them on this simple issue logging form.

Don't forget that this is an alpha release and things may be changed before the final release 2.0.0 release. One thing I'm still up in the air is how we implement  log_params, as such I highly suspect some of the syntax will change in the upcoming weeks.

When will this be officially released? Calendar year 2013 (sound familiar ;-). In all honesty I hope that we can release this by the end of May. Of course the release date all depends on the feedback we get back from you, so please help test!

If you want to follow updates on this project, I'll be labeling all Logger related posts with "logger".
Posted by at
Labels:

5 comments:

  1. Mark LancasterApril 15, 2013 at 4:57 PM

    Excellent initiative Martin, look forward to the new version.

    ReplyDelete
  2. LevApril 17, 2013 at 1:09 PM

    Hi Martin,
    I think it's a very good idea.

    Could I ask ask for 2 features - they are very easy to implement.

    1) Add function logger.ok_to_log to package spec
    This can make code more efficient.

    For instance when I write code

    logger.log(p_text=> Paramerter_Value() ...

    Parameters are calculated even if they are not logged.

    If function logger.ok_to_log was in package spec then I could write

    if logger.ok_to_log('DEBUG') then
    logger.log(p_text=>Paramerter_Value()...
    end if;

    2) make primary key of new record inserted in logger_logs table available to user

    Then I could sent e-mail to the user:

    Your error is logged with id=....

    When user calls support he will say that number and support will easily find
    error message.

    Thanks,
    Lev

    ReplyDelete
    Replies
    1. Martin D'SouzaApril 17, 2013 at 11:19 PM

      Hi Lev,

      1- Let me think about it. I guess the goal is to avoid developers having to write a bunch of "if/else" statements to log items. Just to be clear on your concern is parameter_value a value or a function? If it's a value what do you mean by "it still needs to be calculated"?

      2- I've received another request for this feature as well. I have added your request for the future release list. Odds are we could look at implementing it in a 2.1.0 release.

      Thanks for your feedback.

      Martin

      Delete
    2. LevApril 18, 2013 at 8:53 AM

      Hi Martin,

      Thanks for feedback.

      Developers don't have to write bunch of if/else statements.
      They can use logger.log_* procedures as they always used them.

      I think that logger.ok_to_log is for some special situations.

      For instance:

      v_date_from date;

      ...
      log.log('Date_from:'||to_char(v_date_from,'dd-mm-yyyy'));
      ...


      Parameter of log.log(...) in this example 'Date_from:'||to_char(v_date_from,'dd-mm-yyyy')
      to_char will be calculated even if logger_level is not 'DEBUG'.

      Sometimes (not always) it is better to write it like:

      v_date_from date;
      ...
      if logger.ok_to_log('DEBUG') then
      log.log('Date_from:'||to_char(v_date_from,'dd-mm-yyyy'));
      end if;
      ...

      Thanks,
      Lev

      Delete
    3. Martin D'SouzaApril 18, 2013 at 9:12 AM

      Hi Lev,

      I plan to introduce something similar to log_params but for just a single parameter to be logged right away in a future release. This should resolve parsing the data as you described above.

      We can still look at exposing ok_to_log but we definitely want to discourage users from writing a lot of if/else blocks for logging.

      Thanks for clarifying things.

      Martin

      Delete

Subscribe to: Post Comments (Atom)