search

Dzoukr / Dapper.FSharp

Lightweight F# extension for StackOverflow Dapper with support for MSSQL, MySQL, PostgreSQL, and SQLite
MIT License
365 stars 35 forks source link

Discussion around Dapper vNext #34

Open JordanMarr opened 3 years ago

JordanMarr commented 3 years ago

It looks like Dapper vNext is going to heavily incorporate C# source generators which will break compatibility with F#. It’s probably 3-6 months out, so this would be a good time to discuss impact and possible strategies.

See this tweet

There is also an issue on the Dapper Issues page entitled “Project state?” that discusses it.

JordanMarr commented 3 years ago

My quick analysis of options:

1) Replace Dapper calls with custom code. I personally think this is actually a pretty good option.

2) Do not upgrade to Dapper vNext. Maybe not a terrible option as it would be the easiest approach in the short term, but it may not age as well long term.

Or maybe there is a third option for F# accessibility to C# source generators that I’m missing. ¯_(ツ)_/¯

Dzoukr commented 3 years ago

Hi Jordan,

thanks for the info and analysis. I think we can stick with no.2 for some time (at least until Dapper vNext is at a reasonable state, hotfixed, etc...) and then we can work on Dapper.FSharp v3.0.0.

I wonder what it offers from the developer's point of view. 🤔 I mean... the current state is great and covers most of the scenarios you'd normally need. I could not find much of this information in https://github.com/DapperLib/Dapper/issues/1637.

So maybe we'll just sit, wait and watch Nick for some time to see where is it all heading?

JordanMarr commented 3 years ago

I’m guessing that the purpose would be to replace the reflection based property loader with generated loaders. So the upside will be slightly faster performance for C# users at the expense of compatibility with F#.