Model Defined Functions

re: Model Defined Functions

Kristofer — Fri, 09 Jan 2009 05:13:42 GMT

Sorry, but for consistency shouldn't the DefiningExpression part live in the SSDL rather than the CSDL?

I.e. declare the function's signature in CSDL, declare the function itself in SSDL and map the two in MSL...

I think that would be more consistent with how everything else is done today in EDMX.

re: Model Defined Functions

Kristofer — Fri, 09 Jan 2009 05:27:15 GMT

...or maybe I am misunderstanding what you're trying to achieve.

To make the problem/solution at hand easier to understand - could you elaborate on what are the benefits of defining the ESQL part in the CSDL and/or what problem you're trying to solve?

re: Model Defined Functions

AlexJ — Fri, 09 Jan 2009 08:06:24 GMT

Kristofer,

I'm not sure that there is anything inconsistent about having something live purely in the CSDL.

Having said that declaring and defining (with native SQL) a function in the SSDL and mapping that through to a CSDL declaration is an interesting scenario. And is closely related to something we are considering for Table Value Functions. This is why today if you only have a declaration in the CSDL, it won't fail at metadata loadtime, it means in the future we can support that declaration mapping to something in the SSDL.

Still there are a number of benefits of functions declared and defined purely in the CSDL:

1) The functions don't rely on anything in the MSL or SSDL, i.e. they are fully portable.

2) In eSQL you get to write functions in terms of the conceptual model, rather than in terms of the storage model. I.e. you don't need to worry about things like joins for either inheritance or associations, the existing mapping takes care of that.

3) Since the entity framework can parse and understand eSQL (as opposed to native SQL) we can potentially optimize calls to retrieve only what is required when less than is returned is actually required by the calling code (eSQL or LINQ).

There are probably other advantages but that is what is coming to mind right now.

Cheers

Alex

re: Model Defined Functions

Kristofer — Fri, 09 Jan 2009 08:25:38 GMT

Thanks, that makes it more clear. Esp. #2 is a very good reason for doing this.

re: Model Defined Functions

Kristofer — Fri, 09 Jan 2009 08:32:56 GMT

Will you also allow CSDL functions to map to managed code implementations?

E.g.:

</Function>

That would provide a nice extensibility point allowing plugins that would also be used by 'other' consumers of the model (e.g. reporting tools etc).

re: Model Defined Functions

AlexJ — Fri, 09 Jan 2009 08:40:47 GMT

Kristofer,

We have discussed the possibility of a language attribute on the <DefiningExpression> basically for the scenario you talk about.

However that is definitely more of an V3/V4 kind of a thing, you shouldn't expect to have built-in support for this in .NET 4.0 (i.e. EF v2).

Having said that however it will be possible to not include a DefiningExpression and instead have your own structural annotation (see the post on structural annotations on this blog) i.e.

<mynamespace:ManagedMethod Name="GetPersonAge" assembly="PersonExtensions.AgeCalculator, Version=1.2.3295.12345, Culture=neutral, PublicKeyToken=123412341234ABCD" />

And use that to support other consumers of the model.

Cheers

Alex

re: Model Defined Functions

Kristofer — Fri, 09 Jan 2009 08:45:32 GMT

...and... While we're in on the topic of providing extensibility that can be used by all consumers of the model... How about CSDL functions mapped to webservice (and WCF) calls, e.g.:

</Function>

re: Model Defined Functions

Alex James — Fri, 09 Jan 2009 09:07:24 GMT

Ah, someone who thinks a little like me ;)

Well one of the scenarios I see for <Function>s with no <DefiningExpression>, maybe with structural annotations, is the creation of WebService end points etc.

Given that we are adopting customizable T4 templates for Code Generation (not to mention model first scenarios) in the Entity Framework, I think you can imagine the possibilities.

Alex

re: Model Defined Functions

Kristofer — Fri, 09 Jan 2009 09:51:52 GMT

Neat, will the default code generator in v2 be T4 based?

re: Model Defined Functions

dsimmons@microsoft.com — Fri, 09 Jan 2009 10:58:54 GMT

Yes, the default code generator in v2 will be T4 based, but in a sense that will just be an implementation detail. The interesting part really is just that we will have fully supported templates as a starting point and some tooling integration to make it easy to turn off the default code generator and drop into your project the template so that you can begin customizing it (or even pick from multiple different flavors of templates as starting points).

- Danny

re: Model Defined Functions

juliel — Fri, 09 Jan 2009 16:55:36 GMT

Are we witnessing a job interview here? ;-)

I wonder if anyone has complained that you are putting business logic into the model with this?

Will there be designer support for this? Not for the building the expression itslef but so that you don't have to go into the XML to implement it.

julie

re: Model Defined Functions

juliel — Fri, 09 Jan 2009 17:01:47 GMT

BTW - I wasn't complaining about business logic, just curious about feedback from others. Alex, you know I'm a fan of definingExpression.

julie

re: Model Defined Functions

efdesign — Sat, 10 Jan 2009 01:21:44 GMT

Julie,

I'm sure some will complain. We all have different ideas about how things should be done.

Personally I don't see the conceptual difference between a Model Defined Function and WebService end point. The only difference is that the Entity Framework automatically handles calls to the MDFs.

And given that you can write Model Declared Functions too (i.e. no definition) you can separate out the implementation from the declaration too, if you think that is important.

If you do that of course, then you need to handle calls to the function yourself.

Am I making any sense?

Alex

re: Model Defined Functions

shawn — Sun, 11 Jan 2009 00:09:15 GMT

Would it be possible to do this for non-static functions as well, so that you can write the queries in a more object-oriented way? So instead of:

var peopleOver21 =

from p in ctx.People

where GetAge(p) > 21

select p;

Could you map it such that you could query like this:

var peopleOver21 =

from p in ctx.People

where p.Age > 21

select p;

That way you are calling p.Age instead of GetAge(p)? It seems like that would be a cleaner, more OO way to consume the data in many cases.

re: Model Defined Functions

efdesign — Mon, 12 Jan 2009 05:29:49 GMT

Shawn,

Well it is not something we have done yet. But it is something we are considering. All we need to do is allow the [EdmFunction] attribute on properties and treat the declaring class as the first parameter in the MDF implicitly

Sort of like the reverse of Extension Methods I suppose.

Cheers

Alex

Update on Computed Properties

Entity Framework Design — Tue, 13 Jan 2009 07:27:41 GMT

A while back I wrote a post that introduced the concept of Computed Properties . Since that time we’ve

re: Model Defined Functions

Bruno Santos — Tue, 03 Mar 2009 20:59:16 GMT

Hi. That's a great post! Its exacly what I wanted.

The problem is, it seems the atribute doesn't exist in the VB.NET is that possible?

I can only find 2 sites exposing this subject, yours and this:

http://blogs.msdn.com/efdesign/archive/2008/10/08/edm-and-store-functions-exposed-in-linq.aspx

Entity Framework Design : Model Defined Functions

DotNetShoutout — Thu, 14 May 2009 10:27:05 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: Model Defined Functions

Muhammad Mosa — Thu, 14 May 2009 11:01:38 GMT

As this going to support Linq, the return type of Fucntions that return collection would be of type IQueryable right?

Also in case function return colletion of entities does eager and lazy loading work on this case?!

I also assume it will support POCO entities by default! Am I right?

Entity Framework: функции определенные в модели

progg.ru — Thu, 14 May 2009 16:21:10 GMT

Thank you for submitting this cool story - Trackback from progg.ru

re: Model Defined Functions

Daniel Simmons — Thu, 14 May 2009 17:31:16 GMT

@Muhammad,

These functions are just used to give the function signature for us to figure out how to translate into a part of the overall query sent to the server. As such the return type does not need to be IQueryable--it can be just IEnumerable.

Once the query has been executed and the results returned, if the results are entities, then lazy loading will work the same as for any other entities. Eager loading can also work because this is just a rewrite over the query to bring along extra data.

Yes, it will work fine for whatever entities you have--POCO or non-POCO.

- Danny