* RC2 History Repo
* return the right ValueGenerated if it is mapped to json
* Since Jet doesn't do anything for GO we don't need to do anything like Sql server does
* Update the HistoryRepository
* Remove unused tests
* [GitHub Actions] Update green tests.
---------
Co-authored-by: github-actions <github-actions@github.com>
* Move the SkipTake to its own processor
This handles the queries with Offset and Limit better as there are other linq methods that manage to set the Limit (e.g. First)
MS Access does not have a DateTimeOffset data type so the value should be converted to UTC and saved as a normal date/time
This fixes 2 things
Regression in 7.0 series where the DateTimeOffset was being written as Local time and not UTC.
When reading the value and converting from a DateTime, the Offset value ended up being implicitly set to the systems local time zone offset. A DateTimeOffset from a UTC value should actually have an offset of 0. This has been wrong since the 2.2 series
- Don't derive Timespan and DateTimeOffset type mapping from our JetDateTimeTypeMapping. We can derive from the normal base class for those types
- DateTimeOffset is now mapped to a string. This allows us to round-trip all the details, however any calculations or queries for any components do not work
This makes it easier to use than the extensions (EntityFrameworkCore.Jet.Data.DbConnectionStringBuilderExtensions) with Get/Set methods.
With the new `JetConnectionStringBuilder` class:
```csharp
var csb = new JetConnectionStringBuilder(DataAccessProviderType.OleDb)
{
Provider = "Microsoft.ACE.OLEDB.12.0",
DataSource = @"C:\myFolder\myAccessFile.accdb",
DatabasePassword = "hunter2",
};
var connectionString = csb.ConnectionString;
```
Without the new `JetConnectionStringBuilder` class:
```csharp
var csb = new OleDbConnectionStringBuilder();
csb.SetProvider("Microsoft.ACE.OLEDB.12.0");
csb.SetDataSource(@"C:\myFolder\myAccessFile.accdb");
csb.SetDatabasePassword("hunter2");
var connectionString = csb.ConnectionString;
```
By using `[SupportedOSPlatform("windows")]` at assembly level instead of targeting `net6.0-windows`.
This will enable taking a dependency on the EntityFrameworkCore.Jet* NuGet packages on Linux and macOS. The consumer of EntityFrameworkCore.Jet can then decide how to handle [CA1416][1] either by adding `[SupportedOSPlatform("windows")]`, by targeting `net6.0-windows` or by testing `OperatingSystem.IsWindows()` at runtime.
[1]: https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1416
Christopher Jolly
Laurents Meyer
Cédric Luthi