Heh, sorry, the title is a bit misleading because although my cash reserves have been significantly drained by the purchase of a house, I am not broke. But my code is, now that NH 2.0 has finally been released. This finally means that I can start programming against solid production code. However this release is not without its caveats. NHibernate.Linq has been a project that I have been folowing quite closely and actually using. Back around the time that Beta 2 of NH 2.0 was released, the NHibernate.Linq project was moved into the NHibernate.Contrib project and relatively quickly lapsed into obsolecence as it has not been able to be built against the releases for some time now. I was hopefull that by the time 2.0 was actually released that NH.Linq would be caught up, but alas that was not the case. The reason why is that there is new, better, and refactored linq support on its way for NHibernate and is scheduled for the 2.1 version of NHibernate. That’s great and all but it doesn’t really help poor schmoes like me who want to use the existing linq features for now.
Ok that’s enough whining for now, on to the fixing. The main problem is that criteria queries have lost the property to spit out the name of the persitent class they are linked to. Also some methods have been added to the ICriteria interface and some things have changed in the factory also to do with persistent class names. Using my meager NHibernate skills I think I have worked around all these issues except for one (no more criteria comments) and if you are brave enough you can try the dll or apply the svn patch. All of the tests ran fine for me, but I really havn’t had a chance to play around with it extensively.
This archive includes both a patch for applying to your NHibernate.Linq svn directory, and an NHibernate.Linq dll that is built against NHibernate 2.0GA.
Download at your own risk.
Sometimes a person just has to wait for things to settle down before work can be done. In this case I’m talking about NHibernate 2.0. I had been building off of the latest stable release, beta 1, 2, CR1 etc… However beta 2 seriously broke a bunch of things I’ve been working with as well as Linq support and I’m not sure yet what they intend on doing about it. For instance the latest stable release CR2, has added quite a few new methods to the ICriteria interface that is heavily used by both myself and Linq. One would think that I could just add those methods into the classes that implement them and be done with it, however there is a further snag. The latest SVN source of NHibernate (I would assume this is what NH 2.0 is being developed from) contains an ICriteria interface that is totally different than the one in CR2. So which version is out of date and which one should I use?
Long story short, I’m going to have to wait a bit for the dust to settle before I can reliably continue building against NH 2.0. Ahh but that’s the open source life.
The summer air is getting warmer and I’d rather be outside than inside coding. However that hasn’t stopped work on NHibernate.Remote. Several major changes are in the works and should be out shortly.
1) The generic messaging layer has been improved, unit tests and documentation have been added. It is also now much faster.
2)Support for Criteria Queries and hopefully Linq is being added.
3)Better support for saving entities with non Guid keys.
So if you have been wanting to give this a try, you may want to wait a week untill the next version comes out.
I’ve been spending the last week bug fixing and cleaning up the GenericMessaging library for release. If you don’t know what it’s all about go and check it out. If the front page does not explain it well enough for you then check out the documentation as there are a lot more information and examples in there.
This week while working on NHibernate.Remote I came across an unusual performance problem. When sending objects back and forth across the wire, I need to walk the object graph to ensure that things like lazy sessions are updated to correspond to the local ISession. This is done through a combination of reflection and serialization (which is reflection anyways). I should be doing this in a custom serializer but MS has made it so incredibly difficult to extend the XmlObjectSerializer that I’ve just decided to walk the graph after deserialization. While walking the object graph I need to store the references of objects I’ve already probed so that I don’t end up with an infine loop due to circular references. Anyways due to a combination of poor code and some optimization oversight I ended up with just over 15000 objects in my reference list which was just using a standard generic List<object>. A query for ~1000 records was taking over 4 seconds to complete which simply was not acceptable. At first I thought that it was just an unavoidable consequence of using so much reflection. However in a bid to speed things up a little I ran the Ants analyzer on it. To my complete surprise it was the reference list that was slowing things down. After looking at my code I identified the week points in my code and optimized the amount of references I was storing in the list eventually ending up with ~4000 entries for my 1000 record query. The query was now completing in well under a second.
Even though the problem was solved it still bugged me. I had just mitigated the problem by reducing the amount of entries rather than making the lookup faster. So the same slowdown would be experienced as someone increased the amount of records returned by their queries.
Then today I unexpectedly ran across the solution to my problems. The HashSet<T>. This is a collection that is new in the .Net 3.5 framework and is contained in the System.Core library. It uses indexing to help speed up the Contains() method and boy is it fast. Because it is a set and not a list it cannot contain the same element twice, but that happens to be just perfect for my needs. After implementing the same buggy code using the HashSet<object> instead of List<object> my 1000 record query took ~0.5 of a second to complete. That’s even faster than the optimized code was using List<object>. Of course optimizing is still important, but I gained an important speed boost due to the use of this exciting new collection. I know this will definitely find its way into some of my other projects too.