This release fixes most reported bugs (especially in the reflection optimizer) and introduces various small improvements.

Release notes: NHibernate, NHibernateContrib

Hey. Thanks for the new release and your continued efforts.

So far I've had a couple of issues converting from 1.0.1.

- First the following line fails to work. It was fine in 1.0.1.

with the exception:


- Secondly I get a strange mapping exception with one class which worked fine with 1.0.1. The mapping hasn't been changed and everything looks fine to me. Even stranger is that the initial save works perfectly fine.


Is there any easy way I can find out which property has the issue? I've been unable to find the cause so far.

For the DayOfWeek issue - oops, I introduced this while rewriting the way types are loaded. To work around it, qualify the type name with its assembly name (e.g. "System.DayOfWeek, mscorlib, Version=...")

For the second one - this comes from the reflection optimizer and reporting the property name would slow things down, so you'll have to check every property. Look for mismatches such as having an Int16 property and mapping it as Int32. If you still can't find the problem, open a new thread and post your classes and mappings.

Thanks for the update. Would it be possible to make it so that the SQL parameters are logged under a different name like "NHibernate.Type" rather than "NHibernate.SQL"? i.e. the way it works with Hibernate for Java which uses org.hibernate.SQL and org.hibernate.type. This way you can enable logging of SELECT/UPDATE, etc. statements without seeing all the parameters. Otherwise, there is too much data in the logs if you only want to see the SQL statements.

How are you filtering your log4net statements? We used to log the SQL statements, but I don't remember if the parameters were logged as well.

I think the logging of parameters is something new as of version 1.0.2. It said something about it in the release notes. I'm using something similar to the following for my logging config.



It's not a major issue, just a difference that I noticed from Hibernate for Java.

In the future, I think it would be kind of nice if NHibernate just used .NET 2.0 trace logging (for the sake of simplicity). .NET 2.0 has the TraceSource class now which allows you to divide the trace messages into different categories (something you can't do in prior versions of .NET to my knowledge).

Hmm, when parameters weren't logged, users kept asking for having them logged. When they are logged, they ask for not having them logged :-)

Why I added the logging of parameters (and yes, it's a new feature of 1.0.2): SQL logging is only meant to be used for when you are debugging something, not in production, and in debugging it's usually better to give more information.

I guess I can create a separate logger for parameters, but a) you will have to create a JIRA issue for that, and b) it almost certainly won't be done for 1.0.x.

Hehe. Sorry for being such a pain. ;-) I wouldn't worry about it. It's not that big of an issue. I'd much rather have the parameters than not. I think it's a nice improvement.

I'd much rather have you implement generics support instead. If you do that, I promise never to mention logging again! ;-)

I believe we used to log on the "NHibernate.Loader" to obtain the SQL statements, but that was around NHibernate 0.8 or so.

Sergey & NHIBERNATE Team,

I am not sure if this was brought out before, excuse me if this is a repost.

Anyway, as far as I know Hibernate is under JBoss's umbrella and that includes NHibernate as well. Since JBoss is now acquired by a linux-distro company, will that affect NHibernate in the future? Meaning, will there be a continued support commitment for NHibernate for years to come? I love NHibernate/Hibernate makes my life easier as a developer and I don't want to end up into a dead-end again.

Does it a counterpart of Hibernate 3.x?