Ayende @ Rahien

Just For Fun commented on NHibernate: Nullable DateTime Issues

Sat, 31 Mar 2007 00:40:09 GMT

A good blog entry by Oren (Ayende) about Nullable types and how NHibernate handles them. I am starting

Tomer Gabel commented on NHibernate: Nullable DateTime Issues

Tue, 27 Mar 2007 16:28:18 GMT

I'd imagine that, unless you have a specific requirement to accommodate external dependencies in advance, this shouldn't really be a problem. Is that an actually common scenario? I have relatively little experience developing CRUD applications, so I honestly don't know sort of requirements what to expect.

Ayende Rahien commented on NHibernate: Nullable DateTime Issues

Tue, 27 Mar 2007 16:25:02 GMT

Not all tools support it, unfortunately. Specifically, not all the desingers/ databinding tools

Tomer Gabel commented on NHibernate: Nullable DateTime Issues

Tue, 27 Mar 2007 16:22:05 GMT

Frans, I don't see your point - a proper (C# 2.0) nullable type should be properly handled. If val.HasValue is false, then a null is emitted to the database. Otherwise, the value is emitted. Where is the problem?

Ken Tong commented on NHibernate: Nullable DateTime Issues

Tue, 27 Mar 2007 01:36:37 GMT

AFAIK, default value of nullable int (int?) is null. There should be no born-to-be-dirty problem.

Ayende Rahien commented on NHibernate: Nullable DateTime Issues

Mon, 26 Mar 2007 10:46:07 GMT

A bug is such a harsh term :-) You summarized the problem with nullable value types masterly, From the point of view of the ORM, it cannot know if the value was changed by the user action or because of the nullable mess. It _is_ possible to track changes in the property level, so the ORM would know whatever you set the property or it was set by the ORM itself, but that forces the user to always use the property, which isn't always done. In this case, I would say that the issue is with the code, not with the ORM, using a value type is an indication that all values are valid, so there is no place for a null. Nullable types are an issue, especially the non-native ones, but I don't really see another option.

Frans Bouma commented on NHibernate: Nullable DateTime Issues

Mon, 26 Mar 2007 09:53:35 GMT

No offence, but isn't this a simple bug? I mean, if the field doesn't get changed/set to a value, it shouldn't be seen as a dirty field by NHibernate. It's one of the downsides of comparing values of an entity to save with the 'original' values. Another gem is a nullable int, which likely defaults to 0. When I set it to a value, 0, it's a dirty field and the entity should be saved as the entity is dirty. However, if I DON'T set the field to a value, it's also 0, though it SHOULDN'T be saved, as the field isn't changed and thus the entity isn't dirty. Still saving the entity is a bug, as it will update the field to 0, though that's not the problem. The problem is that a timestamp in the row will get changed as well, marking the field as 'changed' while it's not. These things can have big consequences. Working with non-native Nullable types (thus not the .NET 2.0 ones) can have complications in other tiers, for example in the mud called Winforms (which also has problems with Nullable sometimes. ).