Partager via

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?

Comments

  • Anonymous
    January 07, 2009
    I'm trying to think of what kinds of context you think would make sense to model declaratively... argument level constraints and entity/property level constraints make sense... perhaps some basic validation that's enforced only upon initial create, or only upon an entity being updated (i.e. a modified date property, that's only non-nullable upon update, and must be null on create).  But I get the feeling your envisaging something more all-encompassing, would you see key parts of the model maybe even changing the shape of the entity entirely depending on context... and what would those contexts be??
  • Anonymous
    January 07, 2009
    The comment has been removed
  • Anonymous
    January 08, 2009
    Well I'm definitely not sure. I just have an instinct telling me there is something in this.Although your warning about constraint DSL, doesn't go unheeded.I wonder though, perhaps some sort of Constraint DSL is the natural next step for the EDM? Not sure, but I'm definitely thinking...
  • Anonymous
    January 08, 2009
    PS one option to avoid failing DRY is the use of a core model (akin to the convention) with perspectives (akin to configuration) that tweak the model.What do you think?Alex
  • Anonymous
    January 08, 2009
    The comment has been removed