-
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
Add upsert support and allow arbitrary queries in INSERT, UPDATE and DELETE #85
Conversation
3025f48
to
8484d22
Compare
c0cee0c
to
3ef5ae5
Compare
8484d22
to
ad0b915
Compare
5bdc21f
to
e360dc5
Compare
ad0b915
to
297a73b
Compare
e360dc5
to
5f6f897
Compare
1fb2f67
to
c9d0bd3
Compare
5f6f897
to
9747d8b
Compare
bb7de8a
to
9e927c1
Compare
This also includes a fix for #80. |
f2e1d33
to
ab8b0a3
Compare
ab8b0a3
to
6a38040
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll give this a test soon, but just wanted to mention that I don't like Set
and Where
as type aliases, and find they just get in the way. I won't fight this corner, though - if you disagree, we can keep these.
I actually agree, I was going to get rid of them. I think they had some value when |
…DELETE This PR makes several changes to our "manipulation" functions (`insert`, `update`, `delete`). Firstly, we now support `ON CONFLICT DO UPDATE`, aka "upsert". Secondly, we now allow the insertion of arbitrary queries (not just static `VALUES`). `values` recovers the old behaviour. Thirdly, our `Update` and `Delete` statements now support `FROM` and `USING` clauses respectively, allowing joining against other tables. Fourthly, `Returning` is now an `Applicative`, which means you can say `returning = pure ()` if you don't care about the number of rows affected. In terms of generating the SQL to implement these features, it was unfortunately significantly less work to roll our own here than to add this upstream to Opaleye proper, because it would have required more refactoring than I felt comfortable doing.
872385c
to
b271b0d
Compare
When printing the SQL, we analyse the `PrimExpr`s and `PrimQuery` to detect the case where `rows` is set to `rows = values _` and, if so, we output a bare `VALUES` statement instead of a `SELECT`, because `DEFAULT` is only syntactically valid in a bare `VALUES` clause.
When printing the SQL, we analyse the `PrimExpr`s and `PrimQuery` to detect the case where `rows` is set to `rows = values _` and, if so, we output a bare `VALUES` statement instead of a `SELECT`, because `DEFAULT` is only syntactically valid in a bare `VALUES` clause.
When printing the SQL, we analyse the `PrimExpr`s and `PrimQuery` to detect the case where `rows` is set to `rows = values _` and, if so, we output a bare `VALUES` statement instead of a `SELECT`, because `DEFAULT` is only syntactically valid in a bare `VALUES` clause.
This PR makes several changes to our "manipulation" functions (
insert
,update
,delete
).Firstly, we now support
ON CONFLICT DO UPDATE
, aka "upsert".Secondly, we now allow the insertion of arbitrary queries (not just static
VALUES
).values
recovers the old behaviour.Thirdly, our
Update
andDelete
statements now supportFROM
andUSING
clauses respectively, allowing joining against other tables.Fourthly,
Returning
is now anApplicative
, which means you can sayreturning = pure ()
if you don't care about the number of rows affected.In terms of generating the SQL to implement these features, it was unfortunately significantly less work to roll our own here than to add this upstream to Opaleye proper, because it would have required more refactoring than I felt comfortable doing.