Dzoukr/Dapper.FSharp

Discussion around Dapper vNext

Opened this issue · 3 comments

JordanMarr commented

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

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

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 DapperLib/Dapper#1637.

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

  • 👍2
JordanMarr commented

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#.

  • 👀1