What's new in FinalBuilder 4 - Logging to a database

Ready for another installment of what's new?  There's plenty more we've got up our sleeve, so keep tuned :)

Logging to a database

FinalBuilder versions 1, 2 and 3 record all the log information in memory during a build (this includes when an action starts, finishes, it's status, action lists, errors, output from the tools called, etc - basically everything that FinalBuilder does during a build is logged).  When the build ends (in FB1-3) the log information is written out to an xml file and then stored in a SingleFileSystem with the previous logs.

This approach has the following disadvantages:

1. There is a memory overhead, as the log information cannot be written out until the end of the build
2. Writing the log file at the end of the build can take a considerable time for very big builds
3. The SingleFileSystem used occasionally gets corrupted, and there is no cure except to delete the log file
4. Searching and/or filtering the log is almost impossible and would be very slow
5. Supporting running actions in parallel would be a big job
6. There is significant overhead dealing with large xml files (eg. loading them up to view in Build Log pane)

So, we had to come up with a different approach for FinalBuilder 4 that was extremely fast, very robust and also negated all the disadvantages of the previous FinalBuilder logging architecture.  The logging changes also had to be completely transparent to the user - FinalBuilder 4 has to work in exactly the same way and provide at least the same functionality.  The solution we came up with was to use an embedded database known for it's high performance and it's feature set - NexusDB.  We initially ran some performance tests to make sure it could cope with the type of abuse FinalBuilder could throw at it, and it passed with flying colours, the big challenge was replacing the current logging architecture with the embedded database.  I won't go into gory details, but suffice to say the integration went fairly well mainly due to the decoupled internal architecture of the build engine in FinalBuilder.

The end result is that FinalBuilder 4 now uses an embedded database to handle all the logging, which is written to disk during the build.  The database has very little memory overhead, is able to store and retrieve data very quickly, and will eventually include sorting and filtering of build logs.  Also, logging actions run in parallel was a no-brainer, and loading previous builds in the Build Log has been improved for very large builds.  I won't post a screen pic of FinalBuilder 4 showing off the new database logging in this case, because the UI has stayed exactly the same, except for an extra button “Pack log file“ which is used to reclaim space in the log database.