fix: await PK on create before updating relationships #737
Conversation
NOTE: side-effect is that duplicate ID's might occur when DB does not have a UNIQUE constraint on the FK
Codecov Report
@@ Coverage Diff @@
## stable #737 +/- ##
=======================================
Coverage 92.41% 92.41%
=======================================
Files 181 181
Lines 2018 2018
=======================================
Hits 1865 1865
Misses 153 153
Continue to review full report at Codecov.
|
1 similar comment
Codecov Report
@@ Coverage Diff @@
## stable #737 +/- ##
=======================================
Coverage 92.41% 92.41%
=======================================
Files 181 181
Lines 2018 2018
=======================================
Hits 1865 1865
Misses 153 153
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## stable #737 +/- ##
=======================================
Coverage 92.41% 92.41%
=======================================
Files 181 181
Lines 2018 2018
=======================================
Hits 1865 1865
Misses 153 153
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## stable #737 +/- ##
=======================================
Coverage 92.41% 92.41%
=======================================
Files 181 181
Lines 2018 2018
=======================================
Hits 1865 1865
Misses 153 153
Continue to review full report at Codecov.
|
|
I am now thinking this error is caused by something (presumably lux) parsing the nextVal function into a string causing Postgres to error. |
|
This problem also exists with the update hasOne relationship. |
|
|
…ore updating relationships - undo isNew check in updateRelationships
|
PR has been updated with a new and much better fix. |
|
Any progress on evaluating/merging this fix? |
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.