# Saturday, April 30, 2011

If you are doing work with LINQ, LinqPad is an indispensable tool.  The latest beta release (4.34.2) of LinqPad has added support for connecting to Entity Framework Code First libraries.  As long as your data context is based on DbContext.

Now when you add a connection you’ll get a new option for Entity Framework POCO (4.1 RC). 


Next, you’ll need to browse to your Code First Library:


If you’re data context is based on DbContext (public class YourContext: DbContext) then LinqPad will find your data context:



The last step is to point it to your application / web config file for the connection string:ConnectionString

And voila:


Happy Coding!

Posted 04.30.2011  #    Comments [2]  | 
# 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]  |