-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MERGE queries shouldn't require primary key setting. #100
Comments
Additionally, the fall-back behavior when an on-conflict clause exists but doesn't match the primary keys was super-confusing and I'd suggest that it should return an error rather than just doing an insert. |
Any good news on this issue? |
Would be nice to have @jhajjaarap's patch upstreamed! 🎉 |
@jhajjaarap Perhaps create a pull request for upstreaming your fix? Would love to get that merged. |
I also have trouble with this topic :( Model is:
Query is:
In this case, I expect driver builds "MERGE INTO" sql. But driver builds "INSERT INTO" sql. As a result I got "duplicate key" error. @jinzhu What do you think about this issue? Will there be any updates? 🙏 @ddadaal Can you create a pull request for your fix? 🙏 |
Describe the feature
Merge (upsert) queries currently require all of the columns in
clause.Conflict.Columns
to be primary keys, otherwise it silently falls back to a regular insert.A table can have a primary key thats simply an auto-increment referencing the row, but also unique constraints which can trigger the
ON CONFLICT
case of a merge query.Motivation
Upsert queries that aren't necessarily looking at the primary key.
Related Issues
None.
The text was updated successfully, but these errors were encountered: