Log4Net Success! And nHibernate upgrade goodness..

So in a fit of insanity, I spent all of yesterday evening, on my own personal time:

  • trying to get log4net set up,
  • trying an upgrade to the latest version to see if that would get it working
  • realizing that nHibernate was hooked to log4net and so I had to use nHibernate’s chosen version if I wanted to use the binary
  • said “What the hell” and decided to upgrade my project to nHibernate 1.2
  • FINALLY got log4net working
  • realized that log4net’s working might have been a configuration issue, and had nothing to do with versioning
  • realized nHibernate was seriously busted… whole project was busted
  • rolled back the version updates-hey logging still works!
  • then, went back and methodically tried to upgrade log4net/nHibernate (long as I was in the groove, might as well)

So, there I was, upgrading nHibernate/log4net. Once log4net was working, it seemed to work reasonably well. nHibernate was a fair bit more involved! the iTriggerable interface had a few extra members, which was making things not compile. Interestingly, they recommended extending from an empty version… the idea being that if they add any more crap, they’ll add it to the base class and I can be ignorant. Yay to targeted ignorance!

The more annoying, less obvious issues with the upgrade ended up being ended up being

  1. virtual is now required on all mapped objects. This was a big pain… I’d known about this, but thought it was only needed on the ethods nHibernate interacted with. nope, it’s everything! So I had a TON of places that needed it. Luckily (well, maybe) the code compiled without them, but gave a giant runtime error list missing EVERY method missing virtual, so I’m pretty sure none are missing now!
  2. This may come off as confusing, but bags that hold items that are subtyped need their discriminator in the where.  I don’t see why, this strikes me as duplication, and is fairly yucky.  Not yucky enough to not do the upgrade, but yucky.  The wost part isn’t even clear in the nHibernate documentation… it shows as an example something like  where=”discriminator=’CAT'” but that discriminator is really your actual discriminator column name, so in reality, it might be where=”animal_type=’CAT'” … and you’ve got this in the subclass definition already, so why here?
  3. This last one is probably the most subtle… if you do typeof(myInstanceOfCatClass) you DON’T get CatClass back… you get something like (this is from memory, the idea is correct even if the exact words are not) CProxy_Class_CATCLASS_Proxy .  I imagine this is due to nHibernate’s stronger emphasis on lazy loading, and relying on proxying (thus the virtual importance on everything)  …  however, this broke code, and I didn’t know to look for it.  To get CatClass back , you actually have to call NHibernateUtil.GetClass(myInstanceOfCatClass)

All of the old queries we were using are using Find, and are all giving “obsolete” warnings.  Ah well, see those enough while running Nant, and I’m definitely going to fix every one of those out of sheer annoyance.

Anyway, I’ve alwady written some HQL and gotten a typed collection back. Woohoo!  That was great.  And a colleague helping me on a task out tried making a typed collection in the business objects… and it worked, though she said it only worked with an ICollection, not an IList… weird, something to look into.  So, the key to getting a typed query with the new HQL stuff is that after the CreateQuery where you do List(), you instead do List<CatClass>().  That’s it!  (assuming CatClass is the correct type the query is actually trying to return, otherwise, I suspect you’d get a runtime error)


Leave a Reply

This blog is kept spam free by WP-SpamFree.