You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the introduction of the ability to call sp_invoke_external_rest_endpoint from all Azure SQL Databases this leads to a possible solution to the CLR issue where the CLR function could be reimplemented as a set of Azure Functions.
I see a couple areas of concern.
Is it even possible to duplicate the functionality in Azure Functions
How much duplication and complexity would this introduce
How would this be deployed and maintained for end users
The text was updated successfully, but these errors were encountered:
Personally I now see little value of running tSQLt tests in Azure.
I find that I can just use SQL Server 2022 localdb for all my testing needs.
It does mean that potentially I can't quite use the latest and greatest syntax as and when new syntax gets introduced in Azure but I'm OK with that for the convenience of being able to run on my local machine without having to provision something in Azure.
It is also true that there might be some behavioural differences between localdb and Azure but I don't expect those to impact the unit testing of business logic that tSQLt is for.
With the introduction of the ability to call sp_invoke_external_rest_endpoint from all Azure SQL Databases this leads to a possible solution to the CLR issue where the CLR function could be reimplemented as a set of Azure Functions.
I see a couple areas of concern.
The text was updated successfully, but these errors were encountered: