-
Notifications
You must be signed in to change notification settings - Fork 20
Description
UPDATE: This release will now be v5, to match the fact that it will include explicit .NET 5 support. (Implicit .NET 5 support is already available, and valid - for now - via Mighty's existing .NET Core 3.1 support.)
The other main enhancements in this version will be:
- Finally moving the strongly typed multiple resultset support from the wip branch to the release version
- Also moving
ResultsAssupport from wip to release
Other more minor enhancements include:
- Add
CurrentPageandPageSizetoPagedResultsc.f. Paging enhancements #10 - Correct behaviour on only passing
ProviderNamein the connection string (namely, the provider is set correctly, but Mighty does not incorrectly think that it has a usable connection string) - Add
SqlServerAutoEnlistCommandsToTransactionsflag with defaulttrue, and supporting code, so that if you pass a connection with an open transaction to a Mighty operation, Mighty can just use it SQL Server transaction support #28
The reason this release is a breaking change (semver v3 -> v4) is that I am in the process of writing some code to do an automated audit of all the variant and similarly named methods (e.g. sync vs ...Async, no params vs. ...WithParams, etc., etc.) and I have inevitably found a few minor inconsistencies and missing methods. In order to avoid hard-coding the inconsistencies into tests and baking them into Mighty forever, it seemed preferable to make the changes necessary and release a new major version. This is unlikely to affect you unless you are already using cancellation tokens with async methods, or unless you were using the (incomplete in the previous version) Mighty support for passing in DbConnection, in which case you may have to move some parameters around in your method calls.
The version is stable, I am using it in my own production code; the only reason I've put is as alpha and not beta is that I may still have to make a few more - hopefully small - method signature changes once I've done the last couple of pieces of the automated audit code. I'm hoping to have that done very shortly (i.e. days not weeks).
Finally, up to now I've only successfully been making subsequent versions of Mighty compile compatible, but not necessarily binary compatible. That won't be an issue unless a NuGet package which you're using, is itself using Mighty. Then, it definitely can be an issue, so it's obviously something I can and should (and will!) double-check for, ongoing. (The issue arises around adding, e.g., new optional parameters. Recompiled code will work just fine, but a package compiled against an earlier version won't find the new method and will break.)
To Do
- Add last automated method signature tests
- Finish creating a test harness to test binary compatibility ongoing
- Includes removing all Console output from old Massive tests
- Use Devart license (see below)
- Fix new IAsyncEnumerable problem in .NET Core 2.0 tests (only)
- Take latest minor master branch updates into v4
- Add providerName parameter
- Update built-in providers to use it: if it is present, don't even try to parse the connection string
- Explicit .NET 5 support (should already be implicit support, valid for now, via .NET 3.1 support)