# Friday, April 15, 2011

Life is good.  Compile & deploy!!!!

Over the past few weeks I have been developing a WCF Data Service. We hope to eventually allow for the service to be available to a lot of developers / users outside our control. We have some rather large tables in the service to call against and initially I had set the SetEntitySetPageSize setting to allow server side paging. 

Great until someone asks for everything.  No problem, just set the MaxResultsPerCollection also.

config.SetEntitySetPageSize("*", 25);
config.MaxResultsPerCollection = 100; 

Wait… What’s this?


Hopefully, you’ve already setup your service for debugging.


Specification of entity set page size is mutually exclusive with the specification of MaxResultsPerCollection property in configuration.

Hmmm…  Didn’t see that coming.

You can’t use these two options together.  It’s one or the other.  Pick your poison.

I’m using the March 2011 CTP2 WCF Data Service (latest release at this time).  I’m hoping a future release will allow this.  Seems rather logical to me that we might want to stop someone grabbing 70K rows by accident.

Sure we could handle some of this in the interface we provide to our users but what do you do when a user just does something like this:

ctx = new ServiceName(new Uri("servicelocation"));

DataServiceCollection<ODataExposedTable> exampleCollection= new DataServiceCollection<ODataExposedTable>();
exampleCollection.LoadCompleted += new EventHandler<LoadCompletedEventArgs>(exampleCollection_LoadCompleted);
var query = ctx.ODataExposedTable; //oh boy.... getting everything....

That’s a lot of waiting for 70K records to load…. 

Perhaps this is the point of an OData end point.  Let the end user deal with it…?

Ask and ye shall receive

I posted this question on stack overflow as to why they don’t allow it and got a great response from an MS employee.

Both of these settings are a security/performance feature on the server. The MaxResultsPerCollection causes the server to fail the request if the limit is overrun. The SetEntitySetPageSize allows the server to return only a small part of the data, leaving it up to the client to ask for more if needs to do so. Other than really malicious clients who would bombard your server with many "get me next page" requests, the SetEntitySetPageSize is pretty much superior to the MaxResultsPerCollection. And there are easier ways to make your server suffer if it accepts unlimited number of requests for the client. As to your last question, I think that's actually a good thing that it's up to the client. Some clients might be able/want to handle all the data, no matter how large. Those who don't can stop at any time. Maybe if you could describe the scenario in which you think you would need both... –Vitek Karas

There you have it.  Set the page size and move on.  Don’t worry about the max results.  By setting the page size you are already limiting how much your server gives out at once.

Happy Coding! :-)

Posted 04.15.2011  #    Comments [0]  | 
# Thursday, March 24, 2011

One of the awesome features in MVC is Unobtrusive JavaScript.  In MVC 3 apps you can set this in the web.config.  It’s on by default.

I have a legacy database that has a field that is required and doesn’t allow nulls but the application allows for empty strings to be entered into the field.  I know, what’s the point of requiring a field and allowing empty strings (if empty string actually means something, OK). 

When I set the Required Data Annotation with the AllowEmptyString=true on the field the validator was still returning an error.  On a hunch I set UnobtrusiveJavaScriptEnabled=false and then field began working as expected.

What gives?

MVC 3 uses jQuery validators when UnobtrusiveJavaScriptEnabled is true.  For the Required annotation it uses the jQuery required validator which doesn’t have the AllowEmptyString parameter or one like it.  Essentially, the validator ignores this parameter. Thanks to @srkirkland for pointing this out. And he would know, he runs the OSS Data Annotations Extensions project.

Happy Coding!

Posted 03.24.2011  #    Comments [3]  | 
# Wednesday, March 23, 2011

I’m working on the latest Entity Framework RC 4.1 that comes with Code First. In my quest I learned how the Data Annotations work on empty fields. Something I thought I knew but after being schooled by my simple MVC3 project I had a little help on twitter to set me straight.

I asked on twitter – Do Data Annotation validators run when the field is empty? Required does but my experiment on others don't seem to?

I mean, of course, duh, required would but it didn’t seem like the other validators were.  I was two validators.  The first was the String Length and I had set the Minumim and Maximum Length.  The other was the regular expression validator that wanted 4 digits.  When I emptied the fields, the validator appeared to not run because I didn’t get an error displayed.  If I entered a character then the validation appeared. 

What’s going on? It would make sense that for the String Length validator with a Minimum Length set that when nothing is entered it should fire right?  Clearly, we are below the minimum length.  I began to assume that the validators other than the Required didn’t run if the field is empty.  I always thought they did run. 

Well, @srkirkland to the rescue.  He set me straight.

@klabranche When a field is empty other vals will still run, just return valid always. Convention is non-required vals return true w/ null

…and @srkirkland would know, he runs the OSS Data Annotations Extensions project.

Convention is non-required validators will return true with nulls

I feel as though I should have known this but clearly I didn’t. Maybe, just maybe I had it way deep in the recesses of my mind. A lot of good that did me. :-) How about you?

For the purpose of this post let’s fire up reflector and see for ourselves!

regular expression annotation reflector code

All Data Annotations wield their magic in the IsValid method.  As you can see below the Regular Expression Annotation checks to see if the string coming in is null or empty and if it is return true.

public override bool IsValid(object value)
    string str = Convert.ToString(value, CultureInfo.CurrentCulture);
    if (string.IsNullOrEmpty(str))
        return true;
    Match match = this.Regex.Match(str);
    return ((match.Success && (match.Index == 0)) && (match.Length == str.Length));

How about one more? String Length

string length annotation reflector code 

public override bool IsValid(object value)
    int num = (value == null) ? 0 : ((string) value).Length;
    return ((value == null) || ((num >= this.MinimumLength) && (num <= this.MaximumLength)));

Again, you can see if the initial object coming in is null then return true.

Why this convention

I found a reference on Phil Haack’s blogs:


Notice that if the value is null, we return true. This attribute is not intended to validate required fields. I’ll defer to the RequiredAttribute to validate whether the value is required or not. This allows me to place this attribute on an optional value and not have it show an error when the user leaves the field blank.

Where I went wrong

Back to the String Length validator. If it would fire for an empty string then we are essentially making the String Length validator a required field validator also.  This may seem logical and was my assumption. In reality, if this was true we would be making the String validator also a required validator. Having the convention on all non-required validators return true when their field is empty ensures those validators are not forcing an implicit required.  How fun would that be for a field we wanted to ensure was a certain format but could also be empty?

So there you have it.  I was ready to blame Code First or the Entity Framework, surely not my own assumptions. :-)

Happy Coding!

Posted 03.23.2011  #    Comments [0]  |