Nullable=”False”… but when exactly?

  • Article

If you look at the EDM and in particular the metadata it considers important, one thing is clear: Persistence is the Priority.

For example this:

<Property Name=”Firstname” Type=”String” Nullable=”False”/>

Tells us that the Firstname property can’t be null when persisted.

If however the EDM Type System is used to describe the signature of a function, the Nullable constraint may or may not apply.

You may be able to call the function with an Entity with its’ Firstname property set to NULL, or … maybe not.

Essentially we can’t know whether the Nullable facet (i.e. a persistence constraint) applies in this context.

This distinction makes me think of the contract feature which is coming in .NET 4.0. In that in both situations we are really looking for more validation.

It also makes me wonder whether, in hindsight, it might have been better to have something like this instead:

<Property Name=”Firstname” Type=”String” ssdl:Nullable=”False”/>

Here the ssdl namespace qualifies the nullable constraint. The ssdl is simply shorthand for the storage model or context. The natural implication is that in order to persist the Entity to storage, the Firstname can’t be null. Which in turn further implies, a guarantee, that when materializing entities from storage, the Firstname will never be null.

I wonder if when we look at evolving and growing the EDM, we should be thinking about other contexts too.

Now we’ve taken the first step to supporting other contexts with Annotations, but I wonder if that is enough.

This idea of context seems more fundamental to me.

Its not necessarily (as I think we all thought) just about adding addition information / constraints / whatever, it may also involve, re-defining the same information for a different context.

What do you think?