|«« Transfer Explosion||Backup Management Perspective »»|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
email@example.com no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
An Abuse Trifecta
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
Now is the time I start working on AudioMan collection persistence. That involves remembering the collection the user has put together and reloading it the next time they open AudioMan.
In the first version of AudioMan (version zero, I guess) this was done by serializing the collection as XML and saving it to a file when the AudioMan window was closed. Then the file would be loaded on startup. It was simple but it failed to cover the case where the collection was modified and then AudioMan crashed -- you'd lose all of your modifications. AudioMan didn't crash very often but this error case was brutal.
In AudioMan1 I used hsqldb and a unit-tested database API. This worked alright and covered the error cases where AudioMan crashed before exit. The real pain was maintaining all of that SQL ... oh, and it was slow. Very slow for large collections ... and I have a large music collection. But the real bonus of using a database is that I could query it. With that querying power I implemented a find-as-you-type feature like iTunes.
For AudioMan2 I'm leaning towards hsqldb again but mostly for 1) ease of (non-)installation by the user and 2) because it is written in Java and so is automagically cross-platform with one deployed JAR. I'll reserve opinions on its speed until it's actually running in my Real World situation.
To complement hsqldb this time I'll be trying out Hibernate. Hibernate does something called object-relational mapping (ORM) which is a fancy way of saying it maps Java classes/objects to database schemas/records.
I'm hoping using Hibernate will have a few benefits: 1) I can use other (faster) databases (like MySQL) easily and without porting SQL 2) less manual coding doing synchronizing between classes and database schema, which speeds up development 3) less testing effort because there is less code on my end to test 4) forced seperation of business logic and database-related Java/XML.
Durham will manage the database and use it as a cache so it's not hitting the files to get their metadata every single time, especially when the user is just browsing around the collection.
AudioMan/Durham will also use the database to store information about backup files. Backup files are stored on discs like CD-Rs, not on the "local" hard drive. Backup metadata must be read from the backup disc and stored in the database so it can be accessed at any time.
I'll explain more about how I see AudioMan, Durham and Hibernate interacting in a later post.Posted at April 13, 2005 at 09:51 PM EST
Last updated April 13, 2005 at 09:51 PM EST