Composite pk handling #7453
Open
Composite pk handling #7453
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
FYI: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What did this pull request do?
Ensure that Composite Primary Keys are handled correctly.
Fix issue go-gorm/playground#800
Add new test for FindInBatch with Composite Primary key
User Case Description
When using a struct with a composite primary key, all fields in the primary key should be used in the order by's to ensure that all databases will guarantee returning the same record(s) in the same order every time.
This is applicable to First, Last, FirstOrCreate, FirstOrInit and FindInBatch.
When getting subsequent batches in FindInBatch, the where clause has to take into account all parts of the composite primary key.
First, FirstOrCreate, FirstOrInit Use Case
Expected:
The same record is always returned.
Actual:
At a random, usually under heavy load, the dbms may return a different 1st record, although it has the same value for the 1st column in the primary key.
This Pull:
Guaranteed to return the same record every time as all columns in the primary key are included in the order by statement.
Last Use Case
Expected:
The same record is always returned.
Actual:
At a random, usually under heavy load, the dbms may return a different record, although it has the same 1st column in the primary key.
The record returned may not be the last record when taking all columns in the composite primary key into account, as the order by does not specify all the columns.
This Pull:
Guaranteed to return the same record every time as all columns in the primary key are included in the order by statement.
FindInBatch Use Case
Expected:
All the records are returned in batches
Actual:
A no primary key error is returned
This Pull:
1st issuance for FindInBatch has all columns in primary key in the order by.
Subsequent batches have where clause to ensure that the already consumed batches are excluded, and remaining records are returned up to the batch limit.