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.

Sign up for GitHub

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

Jump to bottom

add support for relationships in update mutations #669

Closed
patcito opened this issue Oct 7, 2018 · 9 comments
Closed

add support for relationships in update mutations #669

patcito opened this issue Oct 7, 2018 · 9 comments
Assignees
@coco98
Labels
a/api/graphql c/server Related to server k/enhancement New feature or improve an existing feature

Comments

@patcito
Copy link
Contributor

patcito commented Oct 7, 2018 •
edited by sassela
Loading

Note from Hasura team: issue closed in favour of #1573

It would be nice to have support for relationships in update mutations like there is in insert so that it automatically delete/add new relationships.

My use case is if a Post table has tags ["x","y","z"] as a relationship in a tag_posts table, if I do an update mutation on post with just tags: ["x","y"] it would be nice if "z" could be deleted automatically from tag_posts table, if you see what I mean. Or maybe add an _unset operator so that we could do _set: {tags: ["x","y"]}, _unset: {tags: ["z"]} to delete "z". That would be more explicit and avoid having people deleting things without knowing. Maybe have an option to _unset all tags that are not set such as {_unsetAllNonSet: {tags: true}}, so in this case that would delete "z".
@shahidhk shahidhk added c/server Related to server k/ideas Discuss new ideas / pre-proposals / roadmap labels Oct 8, 2018
@nolandg
Copy link

nolandg commented May 26, 2019

I've described how Prisma handles this in #1573 (comment)

@bkstorm
Copy link

bkstorm commented Jul 14, 2019

We can learn how Prisma handles this problem (described by @nolandg), they do very well, I think.

@dsandip dsandip added k/enhancement New feature or improve an existing feature and removed k/ideas Discuss new ideas / pre-proposals / roadmap labels Sep 19, 2019
@patcito patcito mentioned this issue Feb 17, 2020
Open
1 task
@LeoMartinDev
Copy link

So, is this still on track ? This feature is clearly lacking

@brianjd
Copy link

brianjd commented Feb 25, 2022

@coco98 Is there a timeline for this? I'm currently working on a problem created by the lack of this feature.

@rccc
Copy link

rccc commented Mar 31, 2022 •
edited
Loading

@marionschleifer @coco98

3 years after this issue is still open, it is a shame that such a feature is still not implemented.

Can we ask a Hasura boss for this ?

Please everyone, contact Hasura directly as i have done myself to ask for this. The Hasura core team have to know we are waiting for this, they have to put someone one this now !

@marionschleifer
Copy link
Contributor

@rccc this is definitely on our roadmap, and we will try to pick it up soon.

An RFC has already been created for it.

@erikkjell
Copy link

@marionschleifer is there an update on this?

@rccc
Copy link

rccc commented Apr 25, 2022

@marionschleifer it seems this issue is the same as #1573

@sassela
Copy link
Contributor

sassela commented Apr 28, 2022

Thanks for this feature request! Closing this issue to deduplicate things, in favour of #1573

@sassela sassela closed this as completed Apr 28, 2022
hasura-bot pushed a commit that referenced this issue Jun 5, 2024
@ecthiender @hasura-bot
fix: ndc validation of command (#669)
52cfca7 
## Description

There is a bug in NDC validation of command where it returns early
without validating. This is because we perform the NDC validation right
after resolving the command source, but haven't attached the "resolved
command source" to the command yet. As a result the command's source is
`None`, and the validation does an early return.

This PR fixes it by taking the command source directly. If there is no
source to resolve, we don't have to perform any NDC validation of the
command.

Note: this is not the case with models. Model's source resolving
attaches the "resolved source", then performs the validation.

## Changelog

- Add a changelog entry (in the "Changelog entry" section below) if the
changes
  in this PR have any user-facing impact. See
[changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
  `no-changelog-required` label to the PR.

### Product

_(Select all products this will be available in)_

- [x] community-edition
- [x] cloud
<!-- product : end : DO NOT REMOVE -->

### Type

<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->

_(Select only one. In case of multiple, choose the most appropriate)_

- [ ] highlight
- [ ] enhancement
- [x] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->

### Changelog entry

<!--
  - Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
  - For Highlights start with a H4 heading (#### <entry title>)
  - Get the changelog entry reviewed by your team
-->

Fix skipping of NDC validation of commands due to wrong assumption.

<!-- changelog-entry : end : DO NOT REMOVE -->

<!-- changelog : end : DO NOT REMOVE -->

V3_GIT_ORIGIN_REV_ID: 5b9f4c922ee83394f1b6fe840cd934b6e138e2e9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@coco98 coco98

Labels
a/api/graphql c/server Related to server k/enhancement New feature or improve an existing feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests