Closed MMagueta closed 1 year ago
Nice. 👍
I have added a simple test, but I am having problems with running them locally on my machine. If someone can build them I would appreciate.
I tested using this script with a database I defined myself:
open FSharp.Data.Sql
open FSharp.Data.Sql.Common
let [<Literal>] vendor = DatabaseProviderTypes.MSSQLSERVER_SSDT
type Schema = SqlDataProvider<vendor, SsdtPath="/Users/mmagueta/Projects/FOSS/TestSQLProvider/base.dacpac">
type Config =
{ Host: string
Port: string
Database: string
User: string
Password: string }
[<EntryPoint>]
let main _ =
let config = {Host = "localhost"; Port = "1433"; Database = "msdb"; User = "sa"; Password = "P@ssw0rd"}
let dataCtx =
Schema.GetDataContext($"TrustServerCertificate = true; Server={config.Host},{config.Port}; Initial Catalog={config.Database}; User Id={config.User}; Password={config.Password}")
let entity = dataCtx.Dbo.TestUddTs.Create()
printfn "%A" <| ((entity.A.GetType().FullName) = "System.Int32")
0
Anything I would still have to go through? If it's ok, I am done with the scope of this PR @JordanMarr
I have submitted a PR to add my old SSDT unit test project back to the test sln. If @Thorium wants to add this back, I think it could be very useful way to add some test coverage around the SSDT provider, including your changes.
Thanks!
I'll release new version tomorrow.
Since UDDTs can only be referenced to simple primitives in SQL Server
You can do user-defined table type like
CREATE TYPE [F#].[Payment] AS TABLE(
[Date] [smalldatetime] NULL,
[Amount] [money] NULL
)
Although I'm not sure if SQL is a good tool for this kind of domain modelling as it's not meant to be a general purpose programming language.
Since UDDTs can only be referenced to simple primitives in SQL Server
You can do user-defined table type like
CREATE TYPE [F#].[Payment] AS TABLE( [Date] [smalldatetime] NULL, [Amount] [money] NULL )
Although I'm not sure if SQL is a good tool for this kind of domain modelling as it's not meant to be a general purpose programming language.
This is somewhat useful for hidden behavior inside procedures (to group a query and insert somewhere from it), triggers (like error handling to persist a rollback), etc; but not so much to expose it via the provider. That's why I parsed a user defined data type only, UDTTs are not even being parsed on the XML from the dacpac.
Proposed Changes
Currently, SSDTs for SQL Server do not support user defined data types. This means if a simple custom type is defined, such as the one from below, the column does not get translated to F#.
A simple UDDT:
From the lsp:
On the following table, where all the types are also simple overloads on REAL and INT:
With this PR we now have:
A further explanation on the implementation may be found under
Further comments
Types of changes
Changes this PR introduces:
Checklist
Further comments
UDDTName
is the given name to the type, andUDDTInheritedType
is the base type thatUDDTName
inherits fromtryFindMappingOrVariant
where such map is passedtypeMappingsByName
map, if it does not find, attempts once again on the UDDT map, if something was found, searches for the base type intypeMappingsByName
, otherwise defaults toSQL_VARIANT
and consequently toSystem.Object