Even after years of application development experience there are still those times where you realize you’ve done something monumenally noobish and the only recourse your left is to face-palm, admit the mistake, and refactor.  I’ll share this story in the hopes that it will help someone avoid a similar snafu.

Noobish Mistakes

When I first began working on an RSS reader desktop app, the requirements called for an offline reading experience which meant caching the content in a local SQLite database.  Another requirement was a simple search feature that could query against the cached feeds.  I thought about how I would go about this and decided that a database schema representing the granular RSS feed elements would give the greatest flexibility for making queries.  This was a decision that seemed to follow established OOP principles but would come back to bite me later.

Trouble Rears its Head

Once I had the database built I began working on the classes for the data model.  I started by extending the xml syndication classes provided by Adobe (the feed I was working with used a custom namespace). Next I defined another set of classes that would take an instance of the syndicated feed or feed item and perform whatever operations were required including reading from and saving to the database.  So far so good.  Once all this was done I began performance testing… and that’s when I realized something was wrong.

As it turns out, SQLite databases aren’t the most efficient things.  I knew this, but I had no idea just how poorly one would perform in the roll I was asking of it.  My process to cache a feed and then retrieve/rebuild from the database was crushing the performance of the app, causing it to go unresponsive during updates.  The only thing to do was to rewrite the database schema to reduce the number of read/write operations. In the end, I decided to save the contents of the RSS feed as a blob.  One feed, one query to read or write — you don’t get any more optimized than that.

Of couse, changing the database schema created a new problem.  Instead of querying the database for the search feature I would need to handle that operation in the application logic.  <sigh>  Oh well, I told myself, at least I had solved the performance problem.

Keep the Data Simple

However, the situation continued to bother me.  I was having to go through a lot of steps to get my data from point A to point B and as I continued to build the application my data model began to feel cumbersome — clunky even.  I’ve been coding long enough to realize that this feeling usually means something is “off” with the application design.  I told a friend of mine about this and as we talked about it he helped me realize just what the problem was.

An RSS feed is just an XML document.  My data model was taking an XML document, carving it up into syndication classes, and then using the syndication classes to populate yet another set of classes.  All that effort when an XML document already had most of the functionality I required.  XPath and E4X support also gave me what I needed for the search functionality.

Lesson Learned

The biggest lesson I learned is to not add unnecessary complexity to my data models.  If all a class does is transform data without adding any new functionality to it, either have a very good reason for the class or avoid it.  When I refactored the database schema I no longer had a real need for all the transformations I subjected the data to.  I had only half way solved the problem.  Or, another way of looking at it, if I hadn’t been so caught up in the beginning on using the database to handle the search  (that is what SQL is good for after all) I’d have seen the potential in XPath and E4X.  Maybe then I’d have thought to refactor the rest of the data model along with the database schema. This was the second lesson I learned: make sure you understand every nuance of the technology you are working with or be prepared to miss something potentially important.

Anyway, I hope this story is helpful to some of you out there.  Enjoy.

•