Nullable types in CSLA.NET 3.6

Nullable types in CSLA.NET 3.6

Old forum URL: forums.lhotka.net/forums/t/6240.aspx

DCottle posted on Thursday, January 22, 2009

If we have a need to use nullable types (which we do), are they pretty safe to use with the framework?  For example, I know that the Validation.CommonRules.MaxValue<T> will break on the type of the parameter being a nullable type...such as CommonRules.maxValue<Int32?>  because this is not an IComparable I get a compile error.  Now, this makes perfect sense to me but I need to know if there are other locations within the framework where it would not be such a trivial matter to add my own code and use that instead to handle the nullable type.

I hope I was clear enough, any questions just ask.

Thanks in advance,

David

Marjon1 replied on Thursday, January 22, 2009

If you are using the SafeDataReader then you need to be aware, that the friendly methods such as GetString, GetInt32 return default values if the dbvalue is null. The only method that returns null is GetValue.

RockfordLhotka replied on Friday, January 23, 2009

In general, nullable types should work just fine in the core of the framework. As noted, there are some peripheral areas, like common rules and safedatereader, where nullable types won't work.

Also, nullable string properties won't work, because CSLA converts null strings to string.Empty. This makes data binding work properly, and is typically a non-issue because few, if any, apps differentiate between null and empty string values. You'd know if you did, because you'd probably have a checkbox next to each textbox so the user could click the checkbox to make the value null (as opposed to just leaving the field empty).

Eric replied on Friday, January 23, 2009

I am new to using the framework (and the book) so forgive me if I am doing something incorrectly.  That said I believe that I have encountered a very significant issue with using nullable types.  Specifically, in a property that utlizes a nullable backing field and property the wrong overload of both GetProperty and SetProperty gets called and the data is lost. 

For example: I have a nullable stateID backing field and a nullable property.  When calling GetProperty(StateIDProperty, _stateID) I always get 0, even when _stateID <> 0.  Stepping into the code reveals that I am stepping into the wrong overload.  It is calling GetProperty<P>(PropertyInfo<P> propertyInfo, Security.NoAccessBehavior noAccess) and passing the value into the enum instead which causes the data loss.

Further, similar issues are occurring with SetProperty(StateIDProperty, _StateID, value), causing data loss.  I am now calling the SetProperty<P>(string propertyName, ref P field, P newValue, Security.NoAccessBehavior noAccess) overload as a workaround.

I verified that this is specific to nullable types and also that it is not just Integer? types.

Needless to say, if I am correct this is a very significant issue for my company.  Any information would be appreciated.

RockfordLhotka replied on Friday, January 23, 2009

Interesting. And unfortunate.

 

You may be able to resolve this with a cast – force the null to a specific type:

 

SetProperty(MyProperty, (P)_stateId);

 

Otherwise the answer is probably to do what you are doing and call the non-ambiguous overloads of GetProperty() and SetProperty().

 

The only broader alternative would be for me to eliminate most of the short-cut overloads and make EVERYONE use the long-form version, which is clearly not a good idea.

 

As you can imagine, the .NET runtime is unable to infer a type for null, and so the overload rules just map it to an arbitrary overload that has the correct number of parameters. You need to somehow constrain the value so the runtime knows that the null value is actually of a specific type. I suspect the forced cast above will do that for you.

 

Rocky

 

 

 

From: Eric [mailto:cslanet@lhotka.net]
Sent: Friday, January 23, 2009 2:43 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Nullable types in CSLA.NET 3.6

 

I am new to using the framework (and the book) so forgive me if I am doing something incorrectly.  That said I believe that I have encountered a very significant issue with using nullable types.  Specifically, in a property that utlizes a nullable backing field and property the wrong overload of both GetProperty and SetProperty gets called and the data is lost. 

For example: I have a nullable stateID backing field and a nullable property.  When calling GetProperty(StateIDProperty, _stateID) I always get 0, even when _stateID <> 0.  Stepping into the code reveals that I am stepping into the wrong overload.  It is calling GetProperty<P>(PropertyInfo<P> propertyInfo, Security.NoAccessBehavior noAccess) and passing the value into the enum instead which causes the data loss.

Further, similar issues are occurring with SetProperty(StateIDProperty, _StateID, value), causing data loss.  I am now calling the SetProperty<P>(string propertyName, ref P field, P newValue, Security.NoAccessBehavior noAccess) overload as a workaround.

I verified that this is specific to nullable types and also that it is not just Integer? types.

Needless to say, if I am correct this is a very significant issue for my company.  Any information would be appreciated.



Copyright (c) Marimer LLC