Test all supported providers

[mikebeaton]

How about this?
#311

[mikebeaton]

The second commit is required, to fix a subtle problem otherwise on the first commit, see #311.

[FransBouma]

At first I thought: "Can you do that?" and whipped up a small program and indeed you can use that dynamic trick to do implicit reflection+property set, neat! It's not that slow either, couple of ms for 1m sets, so it's OK.

Will check the code and merge if everything is ok.

[FransBouma]

Merged

[mikebeaton]

Thanks for this.

Well worth doing the timing test - good point! (I actually found the technique from some other PR in Massive which changed some line(s) of code from not doing that to doing it... at least I think I did! ;) )

Can I ask, I would be very interested to find out more about how you are profiling Massive, more generally...

I've seen that you have references and calls to SD.Tools.OrmProfiler.Interceptor in the Massive tests - that must mean I have installed a Nuget package which is running and collecting data for me when I run the tests (!), but I have never tried to view the results. I did have a quick look and saw that ORMProfiler is a paid license tool (which I guess I wouldn't be looking to pay for in order to be able to (try to!) contribute fast, performant code for free, to an OSS project...).

And I also just recently saw the references in Dapper's Readme.md to your own RawDataAccessBencher and to InfoTechBridge's OrmBenchmark.

I suppose what I'm particularly asking is, as there any performance metrics you are especially looking at when you test a new PR? Presumably, if so, I'm guessing they'd be the ones from using ORMProfiler against the test results and/or keeping an eye on any changes in results from your own RawDataAccessBencher?