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

Implement Update and Delete GraphQL Mutations for all API Objects #102

Closed
Schnitzel opened this Issue Nov 3, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@Schnitzel
Member

Schnitzel commented Nov 3, 2017

Delete

  • Openshift
  • Customer
  • Project
  • Notification
  • SshKey
@Schnitzel

This comment has been minimized.

Show comment
Hide comment
@Schnitzel

Schnitzel Nov 3, 2017

Member

Possible use cases:

  • change branches or enable/disable pull requests
  • add new SSH Key to Customer and/or Project
Member

Schnitzel commented Nov 3, 2017

Possible use cases:

  • change branches or enable/disable pull requests
  • add new SSH Key to Customer and/or Project
@Schnitzel

This comment has been minimized.

Show comment
Hide comment
@Schnitzel

Schnitzel Nov 30, 2017

Member

@ryyppy
I would like to shortly discuss if we are on the right track here.

Overall I think it would make sense to use a MySQL ORM plugin to connect Node to MySQL, especially with the Update handling we are gonna write a LOT of code that I'm not sure if it's worth doing.

Some Research found me
http://docs.sequelizejs.com/
and
https://github.com/mickhansen/graphql-sequelize

Which probably makes a lot of things easier.

What do you think?

Member

Schnitzel commented Nov 30, 2017

@ryyppy
I would like to shortly discuss if we are on the right track here.

Overall I think it would make sense to use a MySQL ORM plugin to connect Node to MySQL, especially with the Update handling we are gonna write a LOT of code that I'm not sure if it's worth doing.

Some Research found me
http://docs.sequelizejs.com/
and
https://github.com/mickhansen/graphql-sequelize

Which probably makes a lot of things easier.

What do you think?

@ryyppy

This comment has been minimized.

Show comment
Hide comment
@ryyppy

ryyppy Nov 30, 2017

Contributor

We should discuss this next week, there is a reason why I didn't consider an ORM, which is much less complexity and more flexibility ... as far as I understand, this whole thing is able to map args with a certain shape of keys into a UPDATE foo (a, b, c) VALUES (aVal, bVal, cVal), which we could quickly write ourselves?

Locking ourselves in a DSL as JS objects will make things much more complicated in the long run

Contributor

ryyppy commented Nov 30, 2017

We should discuss this next week, there is a reason why I didn't consider an ORM, which is much less complexity and more flexibility ... as far as I understand, this whole thing is able to map args with a certain shape of keys into a UPDATE foo (a, b, c) VALUES (aVal, bVal, cVal), which we could quickly write ourselves?

Locking ourselves in a DSL as JS objects will make things much more complicated in the long run

@Schnitzel

This comment has been minimized.

Show comment
Hide comment
@Schnitzel

Schnitzel Nov 30, 2017

Member

@ryyppy

okay, sounds good, let's discuss :) I will then do the delete mutations for now.

Member

Schnitzel commented Nov 30, 2017

@ryyppy

okay, sounds good, let's discuss :) I will then do the delete mutations for now.

@Schnitzel

This comment has been minimized.

Show comment
Hide comment
@Schnitzel

Schnitzel Dec 4, 2017

Member

Had a discussion today with @ryyppy and @karlhorky and this is what we came up with:

  • we will not use a full ORM system like sequelize as we feel that we would buy into something that will cause us more issues in the future
  • for CREATE and DELETE actions we're keeping the current stored Procedure approach (calling a stored Procedure with the actual task that then will do the lifting of the mysql queries)
  • For UPDATE actions we use that approach:
    • we expect in the GraphQL UPDATE Mutation an Input Object only with the parameters that should actually be updated (not the whole object again)
    • the parsing and looping through the object will happen in NodeJS
    • creating the SQL Query for the Update also happens in NodeJS with a helper library like https://github.com/hiddentao/squel
  • We understand that this is a diversion of the current approach (everything in stored Procedures), but for now we fell that's the best approach, as the data crunching for the Update Task is probably too high of what we know about stored procedures
Member

Schnitzel commented Dec 4, 2017

Had a discussion today with @ryyppy and @karlhorky and this is what we came up with:

  • we will not use a full ORM system like sequelize as we feel that we would buy into something that will cause us more issues in the future
  • for CREATE and DELETE actions we're keeping the current stored Procedure approach (calling a stored Procedure with the actual task that then will do the lifting of the mysql queries)
  • For UPDATE actions we use that approach:
    • we expect in the GraphQL UPDATE Mutation an Input Object only with the parameters that should actually be updated (not the whole object again)
    • the parsing and looping through the object will happen in NodeJS
    • creating the SQL Query for the Update also happens in NodeJS with a helper library like https://github.com/hiddentao/squel
  • We understand that this is a diversion of the current approach (everything in stored Procedures), but for now we fell that's the best approach, as the data crunching for the Update Task is probably too high of what we know about stored procedures
@Schnitzel

This comment has been minimized.

Show comment
Hide comment
@Schnitzel

Schnitzel Dec 31, 2017

Member

Update will happen here: #153 closing this

Member

Schnitzel commented Dec 31, 2017

Update will happen here: #153 closing this

@Schnitzel Schnitzel closed this Dec 31, 2017

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