After implementing the native 1:1 relationships support and database default values support in Q2 2012, for the next official version we are going to continue delivering new features based on your feedback. Currently the most popular item in our Public Issues Tracking System (PITS) is “Database Functions Support” so this is the winner you can expect to see in the product as early as Q3 2012, expected to be out very soon! Furthermore, you should know that we have surpassed the initial expectations for this new feature and decided to add a brand new capability to our Domain Methods - read on and learn how you can benefit from it.
In order to provide you an intuitive way of creating Domain Methods for your database functions, we have used the existing Stored Procedure Editor, which is helping you do that for stored procedures for over an year already. The code we generate is leveraging the powerful OpenAccess ADO API to make procedure calls and materialize the results into persistence types, complex (custom) types or scalar types. Introducing the functions support in this dialog made its name inadequate, so we will refer to it as the Domain Method Editor from now on:
It can be used exactly as before, but you are now able to start it for database functions, and even for Table-Valued Functions (TVF) as shown above.
There is one feature however, which was not available for stored procedures, but becomes now possible with the functions. It is the support for using function calls in LINQ queries and forcing their execution on the server. That means the function call will appear in the actual SQL OpenAccess ORM generates. This is configured for you by the Domain Method Editor for all scalar functions by default - it is adding a new attribute called MappedFunctionAttribute to the method definition which is afterwards considered by our LINQ engine. Here is how such function will look like:
As you can see this method defers significantly from what we usually generate for stored procedures. The actual name of the database function is specified in the attribute in order to be included directly in the SQL statement. The method code here is irrelevant as the function will not be executed using the ADO API as the other types of functions or stored procedures are. For that reason we are throwing the NotImplementedException. Note that you can still opt for calling scalar functions separately from LINQ statement using the ADO API; you just have to implement the necessary ADO API code in another method, based on other functions or procedures you might have.
We are happy that we managed to deliver this feature based on your requests and we are sure it will bring value to your applications. Do not hesitate to vote for the rest of the PITS items and you might see some of your favorites in the future releases of Telerik OpenAccess ORM!