[5.2] Return null instead of 0 for a default BelongsTo key #13378
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is for an edge-case when using UUIDs (or any type other than
integer
, really) on postgres.The scenario for this:
other_id
, of typeuuid
other_id
isnull
I'm not sure exactly how to unit-test this, as the error actually happens when you attempt to do a query like so, with
key
as auuid
type, and is in the database layer. Postgres is extremely pedantic about syntax (and will even reject invalid UUIDs).This results in:
I'm not exactly sure if this can be considered backwards-compatible, as it does change the query used by default, but the behaviour should be identical across all supported databases.
The rationale behind using
null
here is because it passes the initial syntax check for all types in all databases. The0
approach is a side-effect of assuming primary keys are always integers (which can also be 0).The only BC break possible would be if someone came to rely on a
BelongsTo
relationship with a "default" value in their database (with an ID of 0) that would always be returned.