codecov[bot]
commented
5 years ago Codecov Report
Merging #737 into stable will not change coverage. The diff coverage is
100%.
@@ Coverage Diff @@
## stable #737 +/- ##
=======================================
Coverage 92.41% 92.41%
=======================================
Files 181 181
Lines 2018 2018
=======================================
Hits 1865 1865
Misses 153 153| Impacted Files | Coverage Δ | |
|---|---|---|
| ...database/relationship/utils/update-relationship.js | 77.41% <100%> (ø) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update 812555a...0b77eea. Read the comment docs.
nickschot
mdconaway
In the case of a belongsTo <-> hasOne relationship Lux attempts to update/overwrite the belongsTo FK. For new records (CREATE) however, this has the side effect of (at least with postgres) not working correctly. It attempts to run the query within the CREATE transaction resulting in a
"nextval(...)"in the query instead of the (currently nonexistent) primary key.NOTE: side-effect is that duplicate ID's might occur when DB does not have a UNIQUE constraint on the FK.This PR has been updated with code to restructure the
createmethod of the model so it await's the insert query before updating the relationships. This way we are sure to have a valid PK (instead of thenextvalstuff).NOTE: The only downside of this approach is that the relationships are not set on validation. It might be possible to set belongsTo relationships before validation, but we must not use the created query yet as that will use an invalid PK.