bitemyapp / bitemyapp/esqueleto
Apply WHERE clause to INSERT SELECT .. ON CONFLICT
- Dominant language
- Haskell
- Stars
- 399
- Forks
- 107
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 1
Description
`INSERT SELECT .. ON CONFLICT .. UPDATE` is currently implemented as [`insertSelectWithConflict`](https://hackage.haskell.org/package/esqueleto-3.3.3.2/docs/Database-Esqueleto-PostgreSQL.html#v:insertSelectWithConflict), which provides basic `upsert` functionality in a fairly nice way.
Unfortunately it's fairly limited compared to Esqueleto's [`update`](https://hackage.haskell.org/package/esqueleto-3.3.3.2/docs/Database-Esqueleto-Internal-Internal.html#v:update) in that it's not possible to constrain what gets updated with a `where_` clause.
The current `insertSelectWithConflict` is nice in that the third argument has the signature:
```haskell
(SqlExpr (Entity val) -> SqlExpr (Entity val) -> [SqlExpr (Update val)])
```
...which provides a concrete list of updates, which can be used to choose between `DO NOTHING` or `DO UPDATE` when the SQL is being generated.
---
I'm mostly opening this issue up so that interested parties can discuss and/or propose a good API for this. From what I've poked around with so far, everything has small compromises in terms of ergonomics or type safety.
---
Related issues/PRs: #131 #155
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the insertSelectWithConflict entry point and compare its third-argument API with update and where_. Review related issues and PRs #131 and #155 to understand prior trade-offs. Done means proposing an API that supports constraining conflict updates while preserving the desired ergonomics and type safety.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- haskell
- Domain
- databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100