left-joined “no related row” data can become a null-id/empty-key related object - and the null throws deprecation warnings.
This fix needs good oversight as it may have wider implications. Approach in the fix- when an alias’s primary key is known and the row has NULL for it, skip that alias entirely; when the key is first learned after hydration, do not store or relate the object if getId() is NULL. This removes the phantom relation while still allowing real 0 or non-null IDs to behave normally.
Tests have been added, but this changes the data. The implementation now skips null primary-key aliases instead of storing them under an empty string.
left-joined “no related row” data can become a null-id/empty-key related object - and the null throws deprecation warnings.
This fix needs good oversight as it may have wider implications. Approach in the fix- when an alias’s primary key is known and the row has NULL for it, skip that alias entirely; when the key is first learned after hydration, do not store or relate the object if getId() is NULL. This removes the phantom relation while still allowing real 0 or non-null IDs to behave normally.
Tests have been added, but this changes the data. The implementation now skips null primary-key aliases instead of storing them under an empty string.
See the minimal fix in this pr: #5334
It eliminates the deprecation message and preserves existing behavior (where without the deprecation it treated it as a string) BUT do we really want to preserve that existing behavior? Probably not- which is what this pr does.