-
Notifications
You must be signed in to change notification settings - Fork 292
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
Deprecate upsert? #796
Comments
In-spite of these caveats, I would still like to use
I would like an API in which we can explicitly specify which uniqueness column it should select. |
Sorry should have clarified: we already have that, it’s |
In that case, I'm fine with it being deprecated. Never actually used |
We could keep |
@MaxGabriel @psibi |
@pythonissam I'd lean toward deprecating I'm going to comment separately on your |
All right. But I think there still exists bugs around these functions. I'm going to organize my thoughts and re-submit issues separately. |
The
upsert
function inserts or updates an existing record. It works fine if there's one uniqueness constraint, but if there are two it doesn't know which to use, and throws an exception. This is pretty lame: you wouldn't think that adding a new uniqueness constraint would cause a runtime exception in a related area of your code. Users should just useupsertBy
, or if their database supports a way of not specifying it, use that functionality (e.g. the MySQL module exposesinsertOnDuplicateKeyUpdate
; I think Postgres requires specifying the column(s)).This would resolve issues like #768 and avoid all the documentation of this caveat in #785.
The text was updated successfully, but these errors were encountered: