Is there a way to define functions in addition to the built in ones(NewGuid, AutoNumber etc) and define how that maps to storage side (SQL) functions and/or CLR functions? (for use with existing or user defined functions for generating defaults on insert and/or update)

Pseudo-code example:

type ModifiedInfo
{
//(optional) attribute specifies thatthe default value is usedon insert only. (default constraint sufficient, no need for trigger inclusion)
[DefaultValueBehavior(InsertOnly)]
CreatedDateTime: DateTime = GetDate();
CreatedByUser: User;

//attribute specifies that the default valueis used on both update and insert. I.e. needs to be included in the update trigger.
[DefaultValueBehavior(InsertAndUpdate)]
LastUpdatedDateTime: DateTime = GetDate();
LastUpdatedByUser: User;
}

type ActiveStatus
{
Active: Logical;
InactivatedDateTime: DateTime = ((!Active) ? GetDate() : Null);
}

//definition of GetDate - uses an attribute for SQL function, code for CLR equivalent
[SQLEquivalent("GetDate()")]
function GetDate()
{
return DateTime.Now();
}

---

Kris

You can always write an M computed value, but that's about creating a query expression of M extents and/or values.

Currently in our bits we do not support the ability to reference T-SQL or CLR functions from within an M file (like doing DLLImport in C#).

But, we are seriously considering a feature to do this.

Tell us what you think of that feature.

You can always write an M computed value, but that's about creating a query expression of M extents and/or values.

Currently in our bits we do not support the ability to reference T-SQL or CLR functions from within an M file (like doing DLLImport in C#).

But, we are seriously considering a feature to do this.

Tell us what you think of that feature.

I think some form of extensibility allowing this would be very useful. An easy and intuitive way would be something like the example above, but if that is not possible then defining GetDate and its' TSQL mapping in a separate assembly and referencing that from within M would work too.

Anyway, I like the code attributes way of defining "extra" stuff/metadataso I would ask you to consider adding support for attributes in M, a set of built-in standard attributes for common customizations(as in the example above), as well as a way of plugging in customized attributes.Customized attributescouldbe defined in a separate CLR assembly along with related functionality for telling the M compiler how those attributes affects the generated T-SQL, or in a fashion similar to the "GetDate" declaration above.

---

Kris

Thanks for the useful feedback, Kristofer. We'll take it into consideration.

You're welcome.

Just a final note - even if you don't add customizable mappings to TSQL and/or CLR functions at least consider GetDate and NewSequentialID.

Those two are the most common non-static default constraints used out there besides identity (AutoNumber).

---

Kris