Ayende @ Rahien

sinm commented on Those are the rules, even when you don’t like them

Thu, 11 Nov 2010 13:06:00 GMT

All these 'rules' are just complex ORM-technology-related excuses in their nature.

Roy commented on Those are the rules, even when you don’t like them

Mon, 08 Nov 2010 07:39:30 GMT

@Richard: We reuse components all the time. I consider it one of the best uses of this feature. As for the workaround, we'll probably end up masquerading the NH behavior using a property that wraps the NH-initialized component and returns null instead of default values.

Richard Dingwall commented on Those are the rules, even when you don’t like them

Sun, 07 Nov 2010 22:36:45 GMT

I always thought components were a bit of a strange way to map something, so I'm not entirely surprised by this behaviour. I guess if you hit this problem, your options are: 1. Model your code in such a way that the component is never null (e.g. invariants, default populated values), or 2. Make the component an entity and reference it via a one-to-one (not nullable) or one-to-many relationship (nullable), or 3. Write a custom IValueType @Roy: unless I am mistaken, your Email class cannot be mapped as a component if it is reused by multiple entities?

Rafal commented on Those are the rules, even when you don’t like them

Sun, 07 Nov 2010 15:44:24 GMT

Roy, thank you for the example,your example made this post clear to me . And surely something is broken when non-nullable fields are allowed to be null - or at least it shouldn't be called the 'expected' behavior.

Roy commented on Those are the rules, even when you don’t like them

Sun, 07 Nov 2010 14:44:06 GMT

@Frans How about an email component, with its own data and behavior. This can be a value type reused by multiple entities in the system, and it can certainly be nullable. It works quite well until I add a "UsedFor" collection to the email. NH breaks the nullability silently - with no warning, instead of null Email components we start getting non-null instances with null Address properties. This breaks the model because Address was defined as not-null in the component. class Email { public string Address {get; set;} // not nullable public void Validate() {...} public void Send(string message) {...} public ISet

Frans Bouma commented on Those are the rules, even when you don’t like them

Sun, 07 Nov 2010 11:07:14 GMT

@Roy however, considering the edge case when one wants a set _inside_ a component (which is a valuetype DDD wise), I don't see why one ever needs it.

Roy commented on Those are the rules, even when you don’t like them

Sun, 07 Nov 2010 08:08:03 GMT

Ignoring the bullshit comments about "the difference between null and empty" and "Set Theory", The question still remains: How do I define a nullable component if that component has a collection in it? It's a perfectly valid OO notion and if NH can't translate that to DB terms it's lacking a feature IMO.

James commented on Those are the rules, even when you don’t like them

Sat, 06 Nov 2010 22:19:11 GMT

Reminds me of the vigorous discussion we had with our Oracle DBA who was of the opinion empty strings should be treated as nulls, due to the mistake Oracle made in their SQL implementation. Happily, he lost :)

Rob Kent commented on Those are the rules, even when you don’t like them

Sat, 06 Nov 2010 09:09:55 GMT

@Dave, "I also urge my developers to also initialize strings to string.empty " I guess that if you obey that convention throughout your code, it might be safe. But what if you actually want a string to have an empty value and that is significant? The purpose of null is to inform you that a field's value has not been set yet. I just have an extension method IsNullOrEmpty which tests for both in one go. In fact, I use IsNullOrEmtptyTrimmed most of the time because I am normally not interested in blank strings.

Dmitry commented on Those are the rules, even when you don’t like them

Sat, 06 Nov 2010 02:20:41 GMT

What happens if you have a struct property in a component? Is the default value considered NULL or the component will be initialized?

Alex Simkin commented on Those are the rules, even when you don’t like them

Fri, 05 Nov 2010 18:35:05 GMT

Assume you have Parent having collection of Children. Now, how you represent the following facts? 1. We didn't yet collect information about children. 2. We did collect information and there is no children, 3. We did collect information and there is exactly n children. 4. We did collect information and there is at least n chldren (but maybe more).

Dave commented on Those are the rules, even when you don’t like them

Fri, 05 Nov 2010 14:13:32 GMT

Any collection should never be null. A collection can be empty, but not null. It's not even NHibernate related if you ask me. It's just bad practice if one of your types contains a collection that can be null. I also urge my developers to also initialize strings to string.empty so you don't have to use object.Equals to do string comparisments without prevalidating (string.IsNullOrXxx) you're strings. But a string is the only class that I use as if it we're a structure..

Steve commented on Those are the rules, even when you don’t like them

Fri, 05 Nov 2010 14:11:59 GMT

I guess if you don't try to remotely understand the concept of a set it could be confusing. It's just one of the fundamentals of Discrete Math.

Dmitry commented on Those are the rules, even when you don’t like them

Fri, 05 Nov 2010 13:54:54 GMT

It makes sense because usually it is a bad idea to allow collections/sets to be null. I do think that it would be more intuitive to initialize a new component instance even if all the properties are truely null.

Jason Meckley commented on Those are the rules, even when you don’t like them

Fri, 05 Nov 2010 12:11:05 GMT

I agree with Peter. Many people have a difficult time understanding null. null doesn't exists, empty exists, there just isn't anything in it.

Peter Morris commented on Those are the rules, even when you don’t like them

Fri, 05 Nov 2010 11:31:39 GMT

It seems they probably didn't know the difference between null and empty. Empty = Known collection of no values Null = No idea what the collection is, might be empty or might not; we just don't yet have the data.

configurator commented on Those are the rules, even when you don’t like them

Fri, 05 Nov 2010 11:09:16 GMT

This feature makes sense from an NHibernate developer's point of view - as you said yourself: "trying to make it not work in this fashion would introduce a lot of work, complexity and additional queries." But from the user perspective it could be puzzling. Perhaps the fact that you needed to explain this means it's doing something that's unintuitive to someone not as fluent in the source as you are. Or maybe not.