Skip to content

Add upsert support and allow arbitrary queries in INSERT, UPDATE and DELETE#85

Merged
shane-circuithub merged 3 commits intomasterfrom
manipulation
Jul 14, 2021
Merged

Add upsert support and allow arbitrary queries in INSERT, UPDATE and DELETE#85
shane-circuithub merged 3 commits intomasterfrom
manipulation

Conversation

@shane-circuithub
Copy link
Copy Markdown
Contributor

@shane-circuithub shane-circuithub commented Jun 29, 2021

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.

@shane-circuithub shane-circuithub force-pushed the manipulation branch 3 times, most recently from bb7de8a to 9e927c1 Compare July 13, 2021 14:31
@shane-circuithub shane-circuithub changed the base branch from projection to master July 13, 2021 14:33
@shane-circuithub
Copy link
Copy Markdown
Contributor Author

This also includes a fix for #80.

@shane-circuithub shane-circuithub force-pushed the manipulation branch 4 times, most recently from f2e1d33 to ab8b0a3 Compare July 13, 2021 16:08
Copy link
Copy Markdown
Contributor

@ocharles ocharles left a 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.

@shane-circuithub
Copy link
Copy Markdown
Contributor Author

I actually agree, I was going to get rid of them. I think they had some value when Where was a -> Query (), as a place to attach documentation to explaining why it's not an Expr Bool, but yeah, they're not necessary anymore.

…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.
@shane-circuithub shane-circuithub enabled auto-merge (squash) July 14, 2021 23:27
@shane-circuithub shane-circuithub merged commit 5d2b9e4 into master Jul 14, 2021
@shane-circuithub shane-circuithub deleted the manipulation branch July 14, 2021 23:31
shane-circuithub added a commit that referenced this pull request Jul 16, 2021
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.
shane-circuithub added a commit that referenced this pull request Jul 16, 2021
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.
ocharles pushed a commit that referenced this pull request Jul 17, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants