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

ON CONFLICT support? #139

Open
taylorfinnell opened this Issue Jun 6, 2018 · 3 comments

Comments

2 participants
@taylorfinnell

taylorfinnell commented Jun 6, 2018

Is adding support for INSERT ... ON CONFICT ... something being considered? I can maybe take a stab at it at some point if it's a wanted feature

@imdrasil imdrasil added the enhancement label Jun 9, 2018

@imdrasil

This comment has been minimized.

Owner

imdrasil commented Jun 9, 2018

@taylorfinnell it is very interesting. Regarding mysql, it has slightly different construction ON DUPLICATE KEY which will complicate providing similar (or at least not very different) interface for postgre and mysql. We should discuss how this should be implemented.

@taylorfinnell

This comment has been minimized.

taylorfinnell commented Jun 10, 2018

How do you think the api should look? Should it be options to #save (possible issues with determining if it is a new record?). Or some other new method like #upsert. Doesn't each adapter have its own sql generator? Can't the differences in ON CONFLICT/ON DUPLICATE be handled there?

@imdrasil

This comment has been minimized.

Owner

imdrasil commented Jun 12, 2018

sorry for such long response - had (and still have -_-) a lot of work. As a starting point may be next points that should be taken into account:

  • new functionality should be realized for Jennifer::QueryBuilder::Query (for generic purposes - to be able to use it without using models) and for Jennifer::QueryBuilder::ModelQuery
  • all sql related stuff should be placed in the corresponding sql generator class
  • the api method name may be upsert - adding extra method (instead of patching existent one) simplify maintainability of code and increase the flexibility of each method; as an argument, we should specify should we ignore cases with duplications or use update (I know that postgres provides more flexible configuratin options, but lets start with simple generic solution)

These are my first thoughts. What do you think about this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment