Posts

One thing that I don’t like about writing tests is some of the jiggery-pokery that goes on with testing database access code. Jiggery-pokery being: ensuring the tables are there, up to date, and are holding the data that they are supposed to hold before and after the test has run. If you don’t pay attention to these details, you get a lot of false negatives on your unit tests. This will result in a loss of confidence in your unit tests. When this happens you stop running them, and loose confidence in your ability to refactor without fear.

Yesterday I was house-bound looking after a sick eight year old boy.  To help pass time, I decided to play around with my chronograph (to clarify: in this context a chronograph is a tool to help you measure the velocity of projecticles, i.e. bullets).  I happen to own a Shooting Chrony Beta Master, which you can, in theory, hook up via a serial port to your computer, download the velocities of up to 60 shots, and use that data to help you with building up some ballisitic tables for your firearm and hand-loaded ammunition.

So last night I installed Visual Studio 2008 RTM on my laptop.  This was a clean install - I did not have any beta versions of VS2008 installed.  When I went to try and do anything in VS2008, I kept getting the message ‘Visual Studio has encountered an unexpected error.".  This error happens when I try to do anything, including VS2008.  The only way to close VS2008 was using Task Manager.  Most annoying.

Lately I’ve come to the conclusion that stored procedures are more of a specialist’s tool than a generalist.  To me, stored procedures are the kind of thing you use when you need to optimize your data access, or you have to do something DB specific.  Sure, I’ve seen lots (and written lots) of stored procedures to do the basic CRUD (mostly in SQL Server, but also in PostgreSQL). These days though, I almost think that one doesn’t need stored procedures for the basic CRUD, only for specific and special cases.

As mentioned in some of my previous blog entries, I’m looking for am embedded database.  At the present, I think that I will remove SQL Server CE for now.  The biggest reason is that, as part of my pet project, the application to run on Mono as well.  So, that kind of leaves SQLite and Firebird. 
Now, in theory, it should matter much between the two for what I want to do.  I’m planning to use ActiveRecord for my data layer, and I see that both SQLite and Firebird are supported.  So, switching between SQLite or Firebird will be pretty minimal.  What about stored procedures, I hear you say?  Well, truth be told, in my old age, I’ve sort of drifted away from stored procedures and look at them with a suspicious eye.  So, the fact that SQLite doesn’t have stored procedures really doesn’t bother or impact me at all.
I’ll do a bit more comparison between the two, and then decided from there which database to use.

Well, as predicted something did distract me from my ActiveRecord experiment.  I got a copy of Genome Express while at an EDMUG meeting recently.  Given that my copy of Genome Express was shiny and new, I installed it and began playing.

My initialize impression is that it’s promising.  I was able to very quickly reverse engineer a SQL 2005 schema and get a heirarchical data model going.  I was able to generate working DAL code for a 12 table database inside of a couple of hours.  About 75% of this time was spent reading the documentation.

Well, after playing with ActiveRecord for about a week and a bit now, and I can say it’s kind of a love-hate relationship.  I like how easy it is to drop in a class, or to make changes to the DB schema and have that reflected in your model.  Contrawise, changing databases should be just as easy.

Troubleshooting is a real bitch, and I find the documenatation a bit on the light side.  Also, on the surface, the parent/child relationships seem pretty easy to setup and configure, but I seem to be having some issues with it.  Also, a familiarity with NHibernate definately seems to be helpful when debugging/troubleshoot.