PolarLava::Blog

PolarBlog V1.11 has been released.  This release contains a major feature enhancement and a number of minor updates and bug fixes.

Enhancements

• New and improved navigation calendar.
• Added optional Archive Entry Calendar view.
• New calendar CSS setup.  There are significant changes in this area!  Please see css/left_nav.diff or css/standard.diff
• Changed default RBL sbl-xbl.spamhaus.org to zen.spamhaus.org
• Changed entry time offset hours range from 24 to 168.
• Updated PHP5Akismet to v0.4
• Update phpMailer to v2.3

• Calendar dates are not falling on the proper day of the week.
• DB class wrapper not properly setting the port value when in MySLQi mode.
• Topic selection in search bar isn't necessary and leads to inaccurate results.
• E_STRICT: Suppress warning in PbEntry::buildTrackbackRdf() from bad charset data.
• E_STRICT: Change declaration of static function FeedCreator::iTrunc to be "public static".
• E_STRICT: Change creation of current time variable from mktime() to time().

• Added USE_ARCHIVE_CAL

• ARCHIVE_LINK_CAL

I, like you was beginning to wonder if there would ever be another PolarBlog release.  After all, it's been nearly 15 months since PolarBlog V1.10.2 was released.  But alas there is a light at the end of the tunnel!

I've updated this blog such that is running Sundial as a beta, the next release of PolarBlog.  So if you see something wacky, please let me know.  The main difference is the new navigation calendar (the one one see in the upper right corner) and also the addition of the (optional) Entry Calendar.  Other that this there are a number of smaller changes and third-party package updates.  So hopefully this will be released publicly in the coming weeks…if I don't get super busy again.

So unknown to me, MySQL changed the way it handles DECIMAL columns between 4.x and 5.0.  Typically this wouldn't be a problem, but when my site was migrated to a new server, it also upgraded it to MySQL 5.0.  And I swear, initially the data was fine.  And based on what I read on the change page it should have kept the old table functionality.  But it would appear sometime over the Christmas holiday —while I was out of town and not paying much attention, they must have dumped and reloaded the database.  And doing that changes the column from the old to new functionality.  (See the last paragraph in the above referenced article.)

Now the ugly part for me…my CycleLog uses DECIMAL to store some of the personal data from my rides (weight, body fat and sleep time).  And unfortunately, the weight column was previously configured as DECIMAL(3,1) which in MySQL 4.x allowed values up to 999.9, but in MySQL 5.x only 99.9.  Thus being my weight is over 100 pounds, all of my rides that had a weight associated with them —that would be nearly all of them, had their weight values reset to 99.9 for all rides.

I stumble upon this when I entered a ride and the weight I entered was showing up as 99.9.  Thus the "huh, what's going on" journey began.  Once I found out about the column change, I altered the table to DECIMAL(4,1), updated my data and it then worked again.

I run a nightly database backups to S3, but I only retain 10 days worth.  Going back to the oldest one, the data was already gone.  And initially I thought my hosting provided might be able to get it back as they thought the old server was still around.  But unfortunately, it had been recycled.  Thus I have no backup with the old data.  I know I've certainly lost at least the last 3-5 years worth of data.  The 2009 data will be fine as I had the data for the couple of rides I had taken.  (I've been sick so I have been riding lately.)  And I have the first 5 years worth of data in my old paper logbooks.  So I should be able to painfully recover that, although my wife has offered to do some data entry for me.  So I may have here enter the date and weight on a spreadsheet, export that to CSV and then write a quick script to reinsert it.  I also may have some more of it archived on a CD somewhere as I used to log it on my Palm for later entry for a few years.  But that likely will be more involved as I'll have to Perl it out of the Palm DB files.

So once the initial shock and disbelief passed, and I accepted the fact that a lot of it is gone forever, I'm left with a tough lesson in data retention.  I'm bummed, but it could have been a lot worse had I lost my whole DB.  It certainly makes me wish I had started to archive the database quarterly like I had been intending to do.  It will certainly happen moving forward though.

And the real kicker?  The personal data was a later add-on to the CycleLog.  I'm not sure why I used DECIMAL there, because the rest of the schema uses DOUBLE.  Had I done that this never would have happened.  ARGH!!!!!!!!!!!

Last weekend I found time to make a minor update to my CycleLog.  The Bikes page now features a lightbox image popup for each of the bike images.  This now allows for a small thumbnail image that can be clicked to view in a larger size.  This is what I wanted to do all along, but didn't have the time back when I added the images.  This was really needed as the original image sizes were too large which resulted in horribly slow page loads.  Plus the reduced image display size looked really lousy.  So all is well now, although I need to update the Centurion Ironman image since the bike was rebuilt.

So after releasing one modification for jpcache, I've now adopted it as a mini-project.  I've used this application for a long time now and have found it to be an absolutely great addition to all of my pages.  In short it allows you to cache complex pages once they are generated and optionally compress the output on the fly as well.  This caching can effectively turn your complex pages into a static pages, thus allowing you to server them up faster.  Additionally you can specify the time between page generation/cache updates from 1 second to indefinitely.

So what's the problem?  I had made a few small contribution to the project a number of years ago and had discussed developing a cache management interface with Jean-Pierre (the "jp" of jpcache).  I actually never pursued this as MyClient was already meeting most of my cache management needs.  But sometimes I just wanted to quickly flush a single-page from the cache.  So I was compelled to develop a page-level flushing mechanism.  This development, after a minor modification was accepted by the project, but never released.

So a good deal of time passed and it became clear the jpcache project unfortunately had ground to a halt.  That's OK, I understand because being the developer of several projects myself, I can easily see how it happens.  Simply put, running a project is a lot of work.  I considered taking up the cause, but I was already managing more projects than I could handle.  It was at this point I released my page level flushing modification as V2.1pl via my blog.  (see below)

So for a longtime I was content with the situation.  Then in early 2008 I learned that jpcache had been taken over and renamed QuickCache.  I was happy to see somebody had taken up the cause and emailed the project lead about my single-page flush modification.  And unfortunately I never heard back from them, nor has this change shown up in the project.

Again I just sort of gave up on it.  But recently I've been looking for a reason to use the PHP SQLite extension simply because I found it interesting.  Thus I opted to (quickly and easily) create a SQLite backend for jpcache.  And at the time of writing this, it's the backend I'm currently using, although that could change in the future.  I thought about submitting it to the QuickCache project, but it appears that it's development is also stalled.  Thus I've opted to release it as "jpcache V2.2" at this time.  See the newly created jpcache project page for more information on this release.

In the future it's possible my jpcache changes could be incorporated into QuickCache should they be interested.  But a more likely scenario would be for me to create a new project branch —which I guess I effectively have at this point.  My reasons for doing this, beyond what's outlined above, is that one of the changes QuickCache made was the elimination of the configuration file.  Personally I disagree with this change and feel the configuration should stay separated from the operational logic as much as possible.  I also still toy with the idea of creating a cache management tool.  But realistically it's more likely I would first modify MyClient to support SQLite databases.  At that point I would again not need a management tool, although it would be nice to add that at some point.  Thus I will be maintaining some version of jpcache for the foreseeable future if for no other reason, my personal need and desire.  So if you're an abandoned jpcache user or simply someone looking for a web page caching solution, this might be a solution for you too!