Skip to content
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

Merged
merged 3 commits into from
Jul 14, 2021

Conversation

shane-circuithub
Copy link
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
Contributor Author

This also includes a fix for #80.

docs/concepts/insert.rst Outdated Show resolved Hide resolved
docs/concepts/insert.rst Outdated Show resolved Hide resolved
Copy link
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.

src/Rel8/Statement/Where.hs Outdated Show resolved Hide resolved
src/Rel8/Statement/Set.hs Outdated Show resolved Hide resolved
@shane-circuithub
Copy link
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