So, a few days ago I blogged about an issue with BlogCFC and MySQL/Access. I was able to reproduce it, but for the life of me, I couldn't figure out why the bug occured. I was able to fix it though, so I've updated the zip. Changes include:

  • Fix for MySQL/Access. More on the issue below.
  • Updated the TrackBack spam list. I highly encourage you to copy this setting even if you don't need the MySQL/Access fix. If all BlogCFC users have a strong TB spam list, it may encourage TB spammers to ignore the platform.

As always, you can download BlogCFC from the project page.

So - more on the bug. The bug was very odd. Basically org.hastings.utils.cfc would throw an error on this line: (I've added a few spaces in it to make it break nicely.)

   view plainprintabout
1  return variables.aDateFormat.getDateInstance( variables.aDateFormat[arguments.style], variables.thisLocale).format(utcDate);

The error stated the value of utcDate wasn't a valid date. Now - this is what I don't get. This CFC hasn't been touched in ages, probably over a year. The date values in the database hasn't changed since BlogCFC was released. Yet there it was - throwing errors. Now - I can say that my dev platform has changed. I used to run the "Simple" CF, ie, install, hook up to Apache, that's it. I've recently switched to CF installed in JRun. So maybe that was the key - but the question is - why hasn't anyone else complained?

Oh - and it gets better. The error was only thrown when you got categories. Let me make this a bit simpler and just paste in the email I sent when I originally asked for help. It may clear things up a bit. What follows is straight from an email, so forgive the fact that it may not match this entry well.

Now here is something that is baffling. BlogCFC has one uber-function to get blog entries. Depending on various filters, I modify the query a bit. For some reason, whenever I tell BlogCFC to get data and filter by a category, I get an error when I try to date format the data. (I'm not using CF's built in dateFormat though.)

I dumped the result of a simple, getEntries, versus a getEntries based on category. In both cases, while the entries were a bit different, the data was, essentially, the same.

On a whim I decided to dump the metadata on the query. For a normal getEntries, the posted column was datetime. For the getEntries/category filter, the value of the column was varchar!

Well - there ya go. Thing is - I can't understand why the query would change the posted column. Here is a sample of the query when doing a normal getEntries:

   view plainprintabout
1  select tblblogentries.id, tblblogentries.title,
2  tblblogentries.alias,
3  date_add(posted, interval -1 hour) as posted,
4  tblblogentries.username, tblblogentries.allowcomments,
5  tblblogentries.enclosure, tblblogentries.filesize, tblblogentries.mimetype
6  , tblblogentries.body, tblblogentries.morebody
7  from tblblogentries
8  
9  
10  where 1=1
11  and blog = ?
12  order by tblblogentries.posted desc
13  limit 4

Now here is the query with a category filter:

   view plainprintabout
1  select tblblogentries.id, tblblogentries.title,
2  tblblogentries.alias,
3  date_add(posted, interval -1 hour) as posted,
4  tblblogentries.username, tblblogentries.allowcomments,
5  tblblogentries.enclosure, tblblogentries.filesize, tblblogentries.mimetype
6  , tblblogentries.body, tblblogentries.morebody
7  
8  from tblblogentries
9  ,tblblogentriescategories
10  
11  where 1=1
12  and blog = ?
13  and tblblogentriescategories.entryidfk = tblblogentries.id
14  and tblblogentriescategories.categoryidfk = ?
15  
16  order by tblblogentries.posted desc
17  limit 4

So - anyone have a bright idea?