Wilson.ORMapper gets a few small updates

I’ve finally gotten around to updating the public open source version of Wilson.ORMapper to match the release formerly known as Subscriber Preview 4.2.2.1. Revision 10 in the SVN repository matches the original 4.2.2.1, but includes the non-restrictive open source license.

I then went one step further — adding a patch which fixes a known bug in WORM. This patch also fixes unit test failures in WilsonORWrapper, which has also been updated to reference version 4.2.2.2 of WORM — the first truly official public release that has some code not provided directly from the original creator, Paul Wilson.

Check out the Google Code project at http://code.google.com/p/wilsonormapper/, or discuss on the WilsonORMapper Google group.

Castle Project has gone RC3

So much has changed since RC2, it makes RC2 look like a beta. 🙂

I’m happy to say that I’m not just a user of Castle projects, but also a contributor (having sent in a few patches related to the Castle Validator).

With RC3’s features and stability, and a nice easy Windows installer available on SourceForge, there’s no excuse for you not to start exploring the power that the Castle Project libraries can bring you.

The NHibernate optimization debate: partial object queries

Aaron (Eleutian) and Oren (Ayende) have a little backandforth going about optimizing NHibernate. I’m no expert on NHibernate, but I do have experience with O/R mappers and even more experience with raw databases and SQL, and on techniques for improving performance on both, so I feel I could chime in at least in one area of their debate…

Partial object queries

Let me bring you up to date:

  • Aaron wants to run an NHibernate query of select u(Username, Email) from User u and get a User object with only those two fileds filled in.
  • Oren says you can do it: select new UserSummaryDetails(u.Username, u.Email) from User u.
  • Aaron disputes that as a solution, since it returns a UserSummaryDetails object and not a User object, which would require him to rewrite methods that work on a User object but only use a subset of fields (he mentions a SendMailTo method which uses only the username and email).

There’s a solution that perhaps can perhaps make both happy. You specify an interface (IEmailInfo) that exposes the Username and Email properties, implement that interface in your User and UserSummaryDetails classes, and use the interface on your SendMailTo method? At least, this seems plausible considering my limited (but growing) NHibernate exposure, and would work in other O/R mappers (like Paul Wilson’s).

Either way, keeping up with the aforementioned blog debate is a good way to understand the inner workings of NHibernate.

ComputerSims Baseball: Powered by MonoRail and ActiveRecord

For the past seven years, I’ve been maintaining an online baseball game, CSFBL (Computer Simulated Fantasy Baseball League). It’s gone through many changes over the years, but its core is in many ways unchanged since 2002 — and therein lies a problem.

Back in 2002, CSFBL was getting about 50,000 to 100,000 page views per month. By the end of 2003, we were simulating about 1,500 games per day. Today, we get about 4 million page views per month, simulate up to 10,000 games per day, and have over 80GB of historical data (roughly 6 million games spanning 2,700 seasons). That’s significant growth — and the game is suffering as a result. It wasn’t built to scale this far – a victim of its own success and my own limitations as a programmer circa 2002.

I realized long ago that a rewrite from the ground-up was necessary. I’ve done extensive work rewriting the database schema to maximize efficiency, but that’s only part of it — I need to rewrite the web site and simulation engine as well. (They currently run on classic ASP and Visual Basic, respectively.)

Originally, the rewrite was going to use WebForms — but that changed when I found MonoRail. Up until two weeks ago, data access relied on Paul Wilson’s O/R Mapper (WORM) and WilsonORWrapper (WORW) — but I just completed the switch to ActiveRecord.

Why abandon WORM/WORW? Three reasons:

  1. I was concerned that I’d run into situations where I needed more power than WORM could provide.
  2. NHibernate and ActiveRecord have incredibly robust communities that dwarf those of the alternatives.
  3. I needed to pick my first ActiveRecord project. 🙂

I still think WORM/WORW are valid choices, but the scope of CSBB is potentially huge, and I knew I needed to follow the leader.

Converting to ActiveRecord was straightforward (one O/R mapper to another), but I did run into one frustrating problem. I had a problem persisting one ActiveRecord classes. Attempting to save it didn’t throw an exception; rather, it just sat there, as if in an endless loop. I traced the call to an NHibernate method call by ActiveRecord, but couldn’t figure out why it wouldn’t do anything. Turning on logging, I recognized the problem: one of my fields (a not null field in the database) wasn’t marked with the [Property] attribute, so it wasn’t included in the INSERT statement. Running the SQL code in MySQL Query Browser threw an error, but not in NHibernate. Frustrating, and possibly an issue with the MySQL provider for NHibernate, but at least I know what to look out for if I see a similar problem in the future.

Still, it feels good to be in the hands of MonoRail + ActiveRecord for the most significant independent, most rewarding, and most unpaid development project of my life. 🙂