Add DbDecimal object

[bsstahl]

This simplifies the syntax that allows queries to run with the same parameter types regardless of the actual size of the data as described in issue #1536.

[bsstahl]

Can I get some input from some of the core contributors on this? Perhaps @mgravell or @NickCraver?

[mgravell]

We will look when we have a moment. Sorry for delay, but we have lots of things on the go, and sadly this isn't our day job.

…

On Mon, 12 Oct 2020, 19:11 Barry Stahl, ***@***.***> wrote: Can I get some input from some of the core contributors on this? Perhaps @mgravell <https://github.com/mgravell> or @NickCraver <https://github.com/NickCraver>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1547 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMFN62OWWSGPX6DZTITSKNBD3ANCNFSM4R3GLP5Q> .

[bsstahl]

While I really hope this item is eventually merged into the codebase, I understand and appreciate that working on this project is a labor of love and not anyone's paying job. That said, my DBAs have been extremely patient in tolerating the lack of consistency in Decimal data-types and the impacts to their tooling and processes. As such I need to move forward with a work-around of some type. It seems to me that my options are the following:

1. Use my fork of Dapper, which contains this change, until the PR is merged, and hope that it eventually does get merged. The obvious drawback here is that we will either miss-out on any changes made to the main codebase, or I will be responsible for keeping my fork in sync with the main one. I can, of course, do this for some time but would prefer not to be responsible for this in the long term. I would also prefer not to put the team through the need to change the tooling now, then change it again later if the PR is merged. All that said, this is not a terrible work-around and is the one I'm leaning toward.

2. Use syntax that exists today and skip the DbDecimal object altogether. This is also not a terrible option and it avoids having to utilize a fork of this project, however it has the drawback of requiring somewhat obscure code to be repeated throughout our codebase. Another drawback is, that while it would not be required to change the code again if this PR is ever merged, it would make sense to do so since the syntax is so much simpler.

3. Add the functionality to each codebase that contains the queries, perhaps using an extension method, rather than to Dapper. While this is not a totally unreasonable option, it feels like the wrong one to me since that functionality clearly belongs to Dapper and would need to be repeated in every codebase that needs it. It could be added to a shared package, but that option is similar to option 1 above with many of the same drawbacks.

If anyone has any recommendations or concerns with any of these choices I would appreciate the feedback. Again, I am well aware of the demands that OSS creators have on their time and I don't want this in any way to be seen as a negative toward the project or its maintainers. This project has been and continues to be an important and valuable one to me and my company.