graphql-engine: One to One relationship causing Not-Null Constraint Violation on Nested Data Insert

{
  "errors": [
    {
      "extensions": {
        "path": "$.selectionSet.insert_a.args.objects[0]",
        "code": "constraint-violation"
      },
      "message": "Not-NULL violation. null value in column \"id\" violates not-null constraint"
    }
  ]
}

The following table definitions reproduce the above error:

Tables

Table a:

Table B:

Relationships

Table A:

Table B:

Invoking The Error

That error happens when inserting data from the “has one” side (table a), but not when inserting from the “belongs to” side (I wish Hasura could label relationships like this as well in addition to what’s there to make things clear quickly):

the above error happens when you run this query:

mutation {
  insert_a(objects: {
    junk_a: "This is a's junk"
    b:{
      data: 
        {
          junk_b: "B's junk inserted when inserting a's junk"
        }
    }
  }){
    affected_rows
  }
}

but not when you run this query from the other side:

mutation {
  insert_b(objects: {
    junk_b: "This is B's junk"
    a:{
      data: 
        {
          junk_a: "A's junk inserted when inserting B's junk"
        }
    }
  }){
    affected_rows
  }
}

This could be related to #2508, but I am not sure cause what he is reporting on is different.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 8
Comments: 25 (8 by maintainers)

Commits related to this issue

fix nested inserts causing not-null violation in one-to-one relationships, fix #2576 — committed to rakeshkky/graphql-engine by rakeshkky 5 years ago
fix nested inserts causing not-null violation in one-to-one relationships, fix #2576 — committed to rakeshkky/graphql-engine by rakeshkky 5 years ago
fix nested inserts causing not-null violation in one-to-one relationships, fix #2576 — committed to rakeshkky/graphql-engine by rakeshkky 5 years ago
fix nested inserts causing not-null violation in one-to-one relationships, fix #2576 — committed to rakeshkky/graphql-engine by rakeshkky 5 years ago

Most upvoted comments

@rikinsk New relationship UI is still missing a insertion order dropdown.

Zerebokep on Aug 12, 2022

@eviefp Is there a PR or commit I can track to see when this actually lands? I’m on 2-beta2 and still hitting this.

corsali-albert on Jun 26, 2021

@0x777 Is this issue still being worked on? Do you have an estimate when this could be fixed? Thanks!

beepsoft on Nov 19, 2019

i’m getting this error too

macalinao on Jul 30, 2019

How can I set insertion_order from the hasura UI?

dalmo3 on Mar 1, 2022

Fix is done and should land in master soon.

eviefp on Mar 5, 2021

For anyone still struggling with this, I was able to get this to work in the UI by exporting the Metadata json file (gear in the top right hand corner of hasura UI), changing the relationships to "insertion_order": "after_parent", save and then Import the Metadata json back into the UI.

famu1hundred on Dec 3, 2022

I had issues similar to this. After doing some research, setting DEFERRABLE INITIALLY DEFERRED on my Foreign Key definition (added this manually to my initial migration script) fixed the issue.

howientc on Aug 1, 2019

as someone has been using hasura for roughly ~2 years in production, this is definitely a candidate for least helpful error messages. super frustrating as a lot of things in hasura just work.

followbl on Jun 15, 2021

Is this still worked on? We are currently designing a new data base model for our cloud platform, and would like to use hasura, but this issue would be a bit of a set back, for our model.

afitzek on Feb 10, 2021

I just stumbled across this issue during the implementation of my API into my Android App.

I have a bills table (table A) and a few subtables (table B) and only the subtables reference to the bills table.

And I have the case where I want to insert through table A but hit this exact issue.

This is a quick mockup of my case:

Bills table has generic bill data
Subtable 1 has Type 1 additional data
- Any bill can have ONE Type 1 row
Subtable 2 has Type 2 additional data
- Any bill can have ONE Type 2 row

So a Bill can have both a Type 1 and Type 2, but only ONE of each.

Thus I cannot make any many-to-(any) relation, at least I dont see where to place it.

I dont want to make the generic bill table reference any Type X subtable as I will get more subtables over time and migrating a huge table in production is not to my liking.

Is there any ETA on a fix for this issue?

Currently my only option to overcome the issue is to first insert into generic bill and after that insert into each subtable manually using the UUID of the bill.

This by no means is my preferred fix as it causes more requests and code to do the same thing, if this where fixed.

AtjonTV on Oct 25, 2020

After further discussion with @rikinsk we finalised on having insertion_order when you are defining a manual object relationship.

{
  "type": "create_object_relationship",
  "args": {
    "table": "author",
    "name": "setting",
    "type": "one_to_one",
    "using": {
      "manual_configuration": {
        "remote_table": "author_setting",
        "column_mapping": {
          "id": "author_id"
        },
        "insertion_order": "after_parent"
      }
    }
  }
}

insertion_order can take two values, before_parent (default and the current behaviour) or after_parent which is needed for ‘one-to-one’ relationship inserts.

0x777 on Sep 5, 2019

@dohomi

But you are saying that with a next update this will be possible from both sides?

Yes. You can follow this issue. We will share a link to a PR build when it is ready.

0x777 on Sep 6, 2019

I had issues similar to this. After doing some research, setting DEFERRABLE INITIALLY DEFERRED on my Foreign Key definition (added this manually to my initial migration script) fixed the issue.

can you pliz give an example script

emahuni on Aug 1, 2019