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

UPDATE ... RETURNING * #572

Closed
schmitch opened this issue Sep 27, 2016 · 15 comments · May be fixed by #1383
Closed

UPDATE ... RETURNING * #572

schmitch opened this issue Sep 27, 2016 · 15 comments · May be fixed by #1383
Labels

Comments

@schmitch
Copy link
Contributor

@schmitch schmitch commented Sep 27, 2016

Version: 0.10.0
Module: quill-jdbc

Actually there is no way of creating a query with UPDATE ... RETURNING *. The problem is that you could create an infix, however every possible query that is available with infix won't actually works for PostgreSQL.

With a simple infix it would create something like that:

SELECT x4.id, x4.customer_id, x4.name, x4.street, x4.zip, x4.city, x4.username FROM (UPDATE crm_address x5 SET x5.name = ?, x5.username = ? WHERE x5.id = ? RETURNING *) x4

However SELECT FROM UPDATE is not a valid SQL command in Postgres.
Another way would be using ActionReturning[T, T] however than you encounter the problem that it can't decode the entity.

@getquill/maintainers

@jilen

This comment has been minimized.

Copy link
Collaborator

@jilen jilen commented Sep 28, 2016

What does your infix looks like ?

@fwbrasil fwbrasil added the enhancement label Oct 5, 2016
@tekacs

This comment has been minimized.

Copy link
Contributor

@tekacs tekacs commented Oct 18, 2016

(just chipping in to request that if this is addressed, DELETE ... RETURNING * also be handled, which we have use for - thanks!)

@schmitch

This comment has been minimized.

Copy link
Contributor Author

@schmitch schmitch commented Oct 26, 2016

There is also no way to say INSERT ... RETURNING * having something like .returning(x => x) it will fail with Can't find Decoder for type 'T'

@mslinn

This comment has been minimized.

Copy link
Contributor

@mslinn mslinn commented Jun 20, 2017

+1: It would be nice to be able to return the entire inserted entry, possibly including any modifications resulting from autoincrement fields.

@andys8

This comment has been minimized.

Copy link

@andys8 andys8 commented Oct 9, 2017

Pretty surprised looking at the API that this is not possible right now. Would be great to add support

@fwbrasil

This comment has been minimized.

Copy link
Contributor

@fwbrasil fwbrasil commented Nov 24, 2017

A solution for this issue should support updates and inserts

@schmitch

This comment has been minimized.

Copy link
Contributor Author

@schmitch schmitch commented Nov 26, 2017

@fwbrasil actually this issue should've add support for update ... returning anything while #973 should've focus on RETURNING * currently update doesn't support .retrungin(_.id) at all.

@pettyjamesm

This comment has been minimized.

Copy link
Contributor

@pettyjamesm pettyjamesm commented Feb 13, 2018

Any update on this? Pretty surprised this common use-case isn't supported at all, and even though the following compiles, it doesn't contain any "RETURNING" clause in the generated SQL:

query[Table].insert(lift(instance)).returning(_.id)

Ideally we would be able to return the whole inserted row.

@jilen

This comment has been minimized.

Copy link
Collaborator

@jilen jilen commented Nov 15, 2018

If infix is not auto wrapped with a map #1179 , this could be implemented use infix.

@rolandjohann

This comment has been minimized.

Copy link

@rolandjohann rolandjohann commented Mar 11, 2019

We came across this issue as well. We return inserted entities as complete row (id, timestamps are generated by DB). With the current implementation we are forced to do a second query to select the previously created entity. Even a workaround of returning multiple fields is not possible with the current API.

I didn't dig deep enough at the code to get an understanding in how complex it will be to implement that feature - if it's possible at all.

EDIT: @pettyjamesm as far as I saw this happens during runtime. Postgres displayed the RETURNING clause at the logs.

EDIT2: maybe someone of the maintainers will respond to the feature request originated in 2016?

@PawelJ-PL

This comment has been minimized.

Copy link

@PawelJ-PL PawelJ-PL commented Jun 8, 2019

+1 for this issue.

@graineri

This comment has been minimized.

Copy link

@graineri graineri commented Oct 16, 2019

Any news about this?

@juliano

This comment has been minimized.

Copy link
Collaborator

@juliano juliano commented Oct 30, 2019

@PawelJ-PL @graineri I intend to start working on this one soon.

@PawelJ-PL

This comment has been minimized.

Copy link

@PawelJ-PL PawelJ-PL commented Oct 31, 2019

Great. It would be great improvement for me. Thank you

@juliano juliano mentioned this issue Nov 29, 2019
5 of 5 tasks complete
@juliano

This comment has been minimized.

Copy link
Collaborator

@juliano juliano commented Dec 17, 2019

@PawelJ-PL @graineri ☝️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.