-
-
Notifications
You must be signed in to change notification settings - Fork 158
Merge v5 into openapi #1150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge v5 into openapi #1150
Conversation
Various small corrections
Note this only works when the database structure is identical for all tenants. Answer to question at https://gitter.im/json-api-dotnet-core/Lobby?at=61e00492f5a394780002705b.
Added example that uses a different database per tenant
Pinned to v6.0.1 due to dotnet/efcore#27436
* Added workaround for bug in EF Core 6.0.2 * Package updates * Downgrade Microsoft.CodeAnalysis to fix cibuild
…ed controller for it. Before, it would use the controller URL from the current request in the Self link, which is wrong.
…ionships from includes
Bugfix: hide Self link in included resources for missing controller
* Added link to 2021 video, reorganized links * Fixed broken API references in documentation
* Removed existing resource inheritance tests * Resource inheritance: return derived types * Resource inheritance: sparse fieldsets * Changed the expression tokenizer to recognize dots in field chains * Resource inheritance: derived includes * Resource inheritance: derived filters * Added ResourceFieldAttribute.Type and use it from QueryExpression.ToFullString() to provide improved debug info * Resource inheritance: sorting on derived fields * Added missing tests for GET abstract/concrete base primary types at secondary/relationship endpoints * Resource graph validation: fail if field from base type does not exist on derived type * Clarified error message on type mismatch in request body * Rename inheritance tests * Added extension method to obtain ClrType of a resource instance (we'll need this later) * Resource inheritance: write endpoints * Updated documentation * Added rewriter unit tests to improve code coverage * Exclude example project from code coverage * Review feedback * Update ROADMAP.md
* Renamed method to avoid clash with built-in method from newer version of FluentAssertions * Package updates * Fix cases for AV1130: Return type should be interface to unchangeable collection * Fix cases for AV1553/AV1554: Optional string/collection/task parameter usage
This prevents future minor/patch releases from unintendedly requiring higher versions of dependent packages, caused by ongoing package updates in the JADNC solution. How NuGet package dependencies in .NET work: - Package references are transient, which means that projects inherit package references from their dependent projects. Therefore there's no need to repeat dependencies in child project files. For example, when project X references package P, and project Y depends on project X, then project Y implicitly references package P (except when P was referenced using PrivateAssets in X). - To use the latest version of a dependent package, it must be referenced explicitly. For example, when package A v1.0.3 references package B v1.0.0, while the latest version of package B is v1.0.2, package B must be referenced explicitly to use its latest version. The rationale here is as follows: - JsonApiDotNetCore* projects (our NuGets) require a pinned version of dependent packages. Currently, these are Microsoft.EntityFrameworkCore and Humanizer.Core. The rest are dev-only dependencies. - Example and test projects explicitly depend on the latest release of EF Core and Npgsql, so we're always building against the latest versions. This enables us to notice breaking changes in patch releases of dependent packages before we release a new version. - Because Microsoft.EntityFrameworkCore* packages are always published together, there's no need to explicitly reference its core package. For example, by referencing just Microsoft.EntityFrameworkCore.Sqlite v6.0.3, we can trust that it depends on Microsoft.EntityFrameworkCore v6.0.3 and nothing else, so there's no reason to explicitly reference Microsoft.EntityFrameworkCore as well. - Npgsql.EntityFrameworkCore.PostgreSQL is maintained by another team, and there's usually a small window of divergence. Therefore we do reference both Microsoft.EntityFrameworkCore* and Npgsql.EntityFrameworkCore.PostgreSQL explicitly.
Pinned versions of dependent packages for the next major release
Added notes on how to create a new release
…n fails with error: Type 'JsonApiDotNetCore.Resources.Identifiable`1[System.Int64]' does not exist in the resource graph. (#1151) The reason for failure is that in an expression like `book => book.Id`, the `Id` property is declared on `Identifiable<>`. The fix is to look at the type of the containing expression (which is `Book` in this case) when the `Id` property is used.
Codecov Report
@@ Coverage Diff @@
## openapi #1150 +/- ##
===========================================
+ Coverage 89.43% 92.24% +2.81%
===========================================
Files 303 302 -1
Lines 8283 8770 +487
===========================================
+ Hits 7408 8090 +682
+ Misses 875 680 -195
Continue to review full report at Codecov.
|
No description provided.