Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion around Dapper vNext #34

Open
JordanMarr opened this issue Jun 6, 2021 · 3 comments
Open

Discussion around Dapper vNext #34

JordanMarr opened this issue Jun 6, 2021 · 3 comments

Comments

@JordanMarr
Copy link
Contributor

JordanMarr commented Jun 6, 2021

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
Copy link
Contributor Author

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
Copy link
Owner

Dzoukr commented Jun 16, 2021

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?

@JordanMarr
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants