- Added the project EFCore.FSharp.FunctionalTests
- Created a fixture for the Northwind database
- Implemented a sample test analogous to the Visual Basic tests
Fixes#14572
* Persist `Id` values into owned collection JSON documents
Fixes#29380
There are several aspects to #29380:
- Constructor binding (already fixed)
- Round-tripping the `Id` property value (addressed by this PR)
- Persisting key values in JSON collection documents (tracked by #28594)
I investigated persisting key values, but identity lookup requires key values in the materializer before we do the parsing of the document. This means persisted key values are not available without re-writing this part of the shaper, which we can't do for 9.
To fix the main issue (round-trip `Id`) this PR changes the way identity on owned JSON collection documents works. Instead of discovering and using the `Id` property, we treat it like any other property. We then create a shadow `__synthesizedOrdinal` property to act as the ordinal part of the key.
We need to discuss:
- Is this breaking for any scenario that was working before?
- Does this put us in a bad place for the future of owned types with explicit keys?
* Added validation of no explicit keys
* Persist `Id` values into owned collection JSON documents
Fixes#29380
There are several aspects to #29380:
- Constructor binding (already fixed)
- Round-tripping the `Id` property value (addressed by this PR)
- Persisting key values in JSON collection documents (tracked by #28594)
I investigated persisting key values, but identity lookup requires key values in the materializer before we do the parsing of the document. This means persisted key values are not available without re-writing this part of the shaper, which we can't do for 9.
To fix the main issue (round-trip `Id`) this PR changes the way identity on owned JSON collection documents works. Instead of discovering and using the `Id` property, we treat it like any other property. We then create a shadow `__synthesizedOrdinal` property to act as the ordinal part of the key.
We need to discuss:
- Is this breaking for any scenario that was working before?
- Does this put us in a bad place for the future of owned types with explicit keys?
* Added validation of no explicit keys
* Experimental support for the Azure SQL json type
Fixes#28452Fixes#32150
Remaining work:
- Test reverse engineering from an existing database
- Output a warning when the native JSON type is used
- Replace the ToJson overload with HasColumnType()
- Move the type mapping visitation to another visitor
Known issues:
- Various issues communicated with the SQL team--see TODO:SQLJSON
- Testing is disabled until we have an appropriate server and driver to test against
* Revert changes needed for testing.
* Fix SQLite tests
* EF code updates
* More review updates.
* More updates,
* Disable Cosmos tests on C.I.
Arthur Vickers
Shay Rojansky
Andriy Svyryd
koenigst
dotnet-maestro[bot]
mianculovici
Jiri Cincura ↹
Andriy Svyryd
Simon Cropp