Wednesday, August 7, 2013

Logger 2.1.0 - ok_to_log

In preparation for the release of Logger 2.1.0 I've decided to write a few posts highlighting some of the new features.

A while ago, someone asked me to add a feature into logger to determine if a log statement would actually be logged. I fought this off like the plague as I wanted to avoid the following situation:
...
if can_log then
  logger.log('some message');
end if;
...

if can_log then
  logger.log('another message');
end if;
...
Unfortunately I've seen this type of coding style many times and it makes code difficult to read and maintain. This also ruins one of the key goals behind Logger which is to make it easy and quick for developers to use.

Reluctantly, I finally caved in. As a result there's a new function called ok_to_log. ok_to_log tells you if what you're about to log will actually get logged. It is not meant to be used like the example above. I can't emphasize this enough.

The main use case for ok_to_log is for situations where you only want to do something for logging purposes that will slow down the system. A good example is when you want to log the values of an array. Since it will take time to loop through the array there's no point in doing it if Logger won't actually log anything. The following example highlights this:
select *
declare
  type typ_array is table of number index by pls_integer;
  l_array typ_array;
begin
  -- Load test data
  for x in 1..100 loop
    l_array(x) := x;
  end loop;

  -- Only log if logging is enabled
  if logger.ok_to_log('DEBUG') then
    for x in 1..l_array.count loop
      logger.log(l_array(x));
    end loop;
  end if;
end;
/ 
If the logging level is set to DEBUG or higher (as it would be in development environments) then logger will loop through the array and log the values. If the logging level is set to ERROR (as it normally would be in production instances) it won't loop over the array since it now knows ahead of time that Logger won't log the values.

Note that the level passed into ok_to_log should correspond to the logging statements used inside the block of code that you want to log. If they don't, it really won't make sense and could result in unnecessary performance hits.

To summarize the ok_to_log function:
- I was reluctant to add it in for obvious reasons, please don't make me regret it.
- Only use in situations where you need to perform an expense block of code only for logging purposes.
- Make sure the level passed in ok_to_log matches the log statements using inside the associated block of code.

Tuesday, August 6, 2013

Logger 2.1.0 - Demo Scripts

In preparation for the release of Logger 2.1.0 I've decided to write a few posts highlighting some of the new features.

The new Logger documentation contains a lot of sample code. Though this is good for documentation purposes I found that I still needed to build a set of demos for various presentations and demonstrations about Logger. Instead of recreating demos each time I've started to keep them in a demo folder (included in each release). This can also be useful for individuals looking to demo Logger at an organization for the first time.

Though not complete, expect the list of demos to expand over time.  If you have a demo script you want added, please feel free to send it to me or make a pull request.

Logger 2.1.0 - Documentation Overhaul

In preparation for the release of Logger 2.1.0 I've decided to write a few posts highlighting some of the new features.

As Logger expands, so does its documentation. We have reached a point that it was no longer feasible to continue with a one page documentation structure. Besides being hard to find a specific bit of information I also found that it was hard to get a quick overview of all the functions that Logger has.

The documentation for Logger has been completely revamped. It's broken up into two main sections: the initial readme file (found on the main project page) and a wiki. The readme file contains a brief overview of logger and links to the wiki. The wiki has been broken up into four sub sections: Installation, Logger API, Change Log, and Best Practices. This is a start to make Logger's documentation similar to Oracle's documentation format which should make things consistent for developers.

If you've already used Logger for a while, take a look at the Logger API page. I think you'll find some functions that you didn't know existed.

The wiki documents are stored in a separate repository on GitHub. This means that they aren't synced with a release is tagged. To get around this issue, each build now contains a folder called "wiki". In it, you will find all the wiki files (in markdown format) generated at the time of the build.

On a side note, the documentation restructuring took a lot of time. I didn't have enough time to document all the functions and they will all be updated in the near future once I have more time. Of course you're encouraged to fork the project and update the documentation if you want to help out.

Monday, August 5, 2013

Logger 2.1.0 - Text Length > 4000 Characters

In preparation for the release of Logger 2.1.0 I've decided to write a few posts highlighting some of the new features.

I must thank Juergen Schuster for suggestion the following change to Logger. He sent me an email with this request and though it took a while to get in, I'm glad to finally see it in this release of Logger.

In the main Logger procedures the first parameter, p_text, is a varchar2 data type. This means that in PL/SQL you can pass in strings up to 32767 characters however the max table size (pre 12c) for a varchar2 is 4000 characters. As you can imagine it caused some people some unexpected runtime errors when they passed in large blocks of text. The only way to get around this was either check the size of text before logging it (if you were unsure of it's final size) or store it in the EXTRA (clob) column.

Starting in 2.1.0, Logger will gracefully handle text entries larger than 4000 characters. If the text is larger than 4000 characters it will automatically be appended to the EXTRA column and a message, "*** Content moved to EXTRA column ***" will be displayed in the TEXT column. I hope this resolves some unforeseen runtime errors that may have occurred in the past.

With 12c finally released (and its ability to have varchar2 columns of 32767 length) this functionality is bound to change / become obsolete. A new issue has been created to address this in a future release of Logger.

Wednesday, July 31, 2013

5 Years Later...

I was working on another post today and noticed that I had just exceed the 400,000 pageviews milestone! The next thing that caught my eye is that it has been 5 years to the day since my first post. So I thought I'd write an article reflecting the past five years.

I started this blog (initially called apex-smb.blogspot.com) to simply post some of code I was working on and elicit feedback from the community. Seemed simple to me: post some code and get free feedback. Over the life of this blog I certainly did get a lot of feedback. I also got a lot more than I had imagined. Since my initial post I have achieved many milestones that I didn't think were possible or hadn't even thought of when I first started. These include:

- Co-founding ClariFit
- Writing several books
- Becoming an Oracle ACE, then later ACE Director
- Working on various open source projects

By far the best outcome is the relationships I've built with people in the Oracle community around the world. This is especially true with the people that I looked up to (and still do) when I first started working with APEX (called HTMLDB back then).

I'm not going to say that this blog is the sole reason for everything that took place over the past 5 years. There were a lot of people that helped support and encourage me along the way. Without their continued support I don't think I'd be in the positive situation that I am in today.

This blog started out as a fun side project with no real motive other than to share code and help improve my writing skills. Turns out it changed a lot for me and went well past its initial intentions. The only "negative" thing (and I use the term very loosely) is that over the past few years I haven't had the same amount of time that I would like to allocate to writing articles at the same pace when I first started. This is primarily due to running a company, writing various books, working on open source projects, and my speaking engagements (and yes I realize that these are all "first world problems").

Going forward I plan to still continue writing. It's something that I really enjoy doing and I hope you, as a reader of this blog, enjoy as well.

Looking forward to the next 5 years!

- Martin