I just found myself writing this in an email:

Let me repeat this "multi threading with drag & drop"...

I'm going to have a liedown.

I just added support for <componet> and <dynamic-component> (in the SVN only, for now).

I'm considerring adding support for projections and the new expressions in NHibernate 1.2, any suggestions? I though about something like:

And:

Suggestions?

Let us assume that you have an architecture that demands that you'll have a database per client (quite common, by my experiance), but the application layers are the same. This is usually done for reasons of security and/or scalability. So there is no way a client can get information for another client.

This is fairly simple to handle with NHibernate, you just create a session factory per each client. This is actually an advantage, since you can start playing with the implementations of the classes for each client. (Yes, you are reading me correctly. In this case, it possible to turn NHibernate into an Inversion Of Control container).

The issue turns up when you have caching turned on. Assuming you have an entity of the same type with the same identifier in two of the databases, you may very will mix the data when it is cached. NHibernate maintain a single second level cache per session factory, so you are supposed to be safe from this. The problem is that the cache space is shared (and it has to be shared).

Let us take an example of an Employee object with id of #5, which exist in both IniTech and Fuzbar databases. When the employee instnace is loaded and put in the cache, the cache key that is used looks something like: "NHibernate:Entities.EmployeeManagement.Employee:5@5". Now, when we try to load an employee from the second database, we first lookup in the cache, finding that there is an instance there, because the cache keys matches.

This is happening because the cache space (so to speak) is the same space for all the caching strategies. For SysCache, it is the ASP.Net cache that is used for the cache space. For distributed caching, Memcached is used. In both cases, if the same cache key is generated, the information will be returned even if the key was actually inserted by another session factory.

In this sceanrio, I solved the issue by modifying the SysCacheProvider to be aware of the current database, and insert the current database name to the cache key. This solved all the issues in one stroke.

The JIRA issue for this is here. I was surprised to learn that I was the first to encounter this, and in the comments to the JIRA issue, I found that indeed I wasn't the first. :-)

The issue is solve by specifying cache region prefix in the session factory configuration, but the functionality wasn't ported to NHibernate yet.

Okay, here is an interesting issue. I am currently building a big project using NHibernate 1.0.2, and I need some features on NHibernate 1.2, mostly with regard to the new critieras. At the moment, we can't move to 1.2, there are concerns about it being beta and other changes that will keep us busy with technical stuff rather than building business stuff. Those are valid concerns, but I still feel that it will take more time in the end to move to the new version.

I can solve the problem with 1.0.2, but not cleanly. I can back port the new stuff that I need (basically, a single class) and use it against NHibernate 1.0.2 (without modifications to NHibernate). The issue I wonder about is how to prepare for the eventual move to NHibernate 1.2. The last thing that I want is to have two ways to do something, or using the inferior method to handle it.

I already have a big comment right there:

 Any other suggestions?

I found that I need to group a collection by a certain attribute of its member quite often. Usually because I'm trying to do some crazy things with deeply nested and timed to put some data on the screen.

Anyway, here is the code:

It is not earth shattering or anything like it, but it is going to make a lot of tasks a lot easier now.

(BTW, this is now a part of Rhino Commons).

For a while, I was sure that I had a spyware on the machine, but it turned out to be just VS2005 SP1 Beta1 installer (from now on, known as SP1, because it is quite a mouthful).

It kept pegging the CPU for about 20 minutes!

At least I managed to uninstall it and got back my Web Application Projects.

It took amazingly short while for me to decide that SP1 Beta1 is not going to work for me.

Here is what I get when I try to create a new WebForm in my application:

I'm going to try reinstalling, but if it isn't working, then it is going away.

I got a couple of complaints about regression in NHibernate Generics 1.0.11, about using an abstract class. I hope that this would fix the issue.

Code and binaries are here

I just found the text below on the NUnit forum (removed since then), and I couldn't stop laughing.

I will be going to look for my tinfoil hat now...

Yesterday the beta for NHibernate 1.2 was released, the new features that interests me are:

• Native generics (you no longer have to use the NHibernate.Generics compatability library).
• Batching support (SQL Server only) - huge perforamance increase in some scenarios.
• Support for using Stored Procedures.
• Support for named connection strings.
• SQL Server 2005 and SQL Server 2005 Everywhere dialects
• Parametrized types and User Collection Types - for the really advanced scenarios :-)
• Support for projections in criteria queries - This one looks especially interesting

• IL-based reflection optimizer - another big performance boost.