Code First F# SQL DDL and migration generation from F# types? (maybe another related project)

[jkone27]

Would be great to allow a form of code-first DDL generation also for this provider,

so that common EF-core code-first operation could be completely replaced by this provider within a script for DB generation, eventually such scripts could be versioned, etc...

maybe it could reuse efcore types for this purpose?

something like

type MyOther {
      Id: Guid
      Name: string
}

type MyRecord = {
      Id: long
      Name: string
      PublicIdentifier: Guid
      Others: MyOther list // should identify implicitly or explicitly such relations a bit like efcore does
}

let migration =  ctx.migrationWith "dbo.MigrationTableName" (createIfNotExist = true) // or maybe also default this value if not provided by 

migration 
|> createSchema "test"
|> create<MyRecord>
|> withPrimaryKey _.Id
|> withUnique (_.Name, _.PublicIdentifier)
|> runAsync
|> Async.RunSynchronously

[Thorium]

I recommend using the SSDT for database schema generation and versioning. That works very well as you can have different SSDT schemas in different git branches if needed, and use them from SQLProvider.

I have no idea if Postgres has similar tools as well (the internet says https://metacpan.org/pod/sqitchtutorial ), and I think we could add support for something like that (as just another new provider implementation in SQLProvider). I'm not sure if non-forward code-first migrations ever pay-off. It's a nice idea on paper, but in real life trying to return to the past seems to be harder than in theory.

For F# domain:

• Part of the idea of type-providers is that they are compiler plugins and not code-generators. So there will be no all the maintenance issues that the code-generator provides, for example a) impedance mismatch between abstraction layers, b) updating F# version, c) generation infrastructure problems, d) string-parsing e) picking accidentally the non-favourite or not-well-maintained tool for ast (of tools like e.g. Quotations/Fantomas/Fabulous.Ast/Myriad/...) d) someone modifying generated code preventing re-generation, e) and so on.
• This type-provider is erasing type-provider. It will compile the types away. So the domain-structure you see, the "ORM" part, even when felts like EF-user-experince to the developer, is compiled away by the compiler. At runtime, it's all just very lightweight dictionaries, not mapping layers and layers of objects. Totally different experience of the lovely EF debugging.

[jkone27]

interesting points thanks😊