You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Correct behaviour on only passing ProviderName in the connection string (namely, the provider is set correctly, but Mighty does not incorrectly think that it has a usable connection string)
Add SqlServerAutoEnlistCommandsToTransactions flag with default true, 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)
The text was updated successfully, but these errors were encountered:
Devart have very kindly provided a free license to the project. ❤
This is for the purpose of testing Mighty against the Devart driver on .NET Core, since there is no free version of Devart.Data.MySql for .NET Core. (I had all the .NET Core Devart tests working using their time-limited trial license, but hadn't been able to run them more recently until getting this support from Devart.)
I have added code to the test suite to look for a license key in a named file and use it in the .NET Core Devart tests (only). Because it's not open source the license key file is not in source control, but there is an easy way to disable the .NET Core Devart tests if you don't have a Devart .NET Core license and do want to run all the rest of the test suite (including Devart in .NET Framework, which still tests against the free version), this is commented here.
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:
ResultsAs
support from wip to releaseOther more minor enhancements include:
CurrentPage
andPageSize
toPagedResults
c.f. Paging enhancements #10ProviderName
in the connection string (namely, the provider is set correctly, but Mighty does not incorrectly think that it has a usable connection string)SqlServerAutoEnlistCommandsToTransactions
flag 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 #28The 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 inDbConnection
, 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
The text was updated successfully, but these errors were encountered: