-
-
Notifications
You must be signed in to change notification settings - Fork 158
Fix exception propagation #1021
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
Conversation
…ed while disposing PlaceholderResourceCollector that threw too, resulting in a 500 error response. And it produced noisy logs in cibuild, coming from ExceptionHandler. This commit swallows the second exception so the original one can propagate through the pipeline as intended.
…e that not specifying it results in EF Core configuring this relationship using an identifying FK on the dependent side (Shipment), which is a type of modeling that does not make sense in the scope of JSON:API.
320eab6
to
451bb32
Compare
…d to use an explicit foreign key accordingly. It turns out that not in all cases this makes a difference. I wonder under which circumstances EF Core chooses to use an identifying foreign key and when it does not.
8a68a7a
to
77be4ff
Compare
I considered adding a note to our documentation on HasOne, but it's not entirely clear to me when EF Core chooses to create an identifying foreign key. It does not always do that (see commit details). One condition is that the primary keys of both resources must be of the same type, which usually is not the case in our examples. |
Codecov Report
@@ Coverage Diff @@
## master #1021 +/- ##
==========================================
- Coverage 91.49% 91.47% -0.03%
==========================================
Files 275 275
Lines 7668 7671 +3
==========================================
+ Hits 7016 7017 +1
- Misses 652 654 +2
Continue to review full report at Codecov.
|
Fixes #1017.