Autogenerated `MERGE` Mutations (`updateOrCreate`) about graphql

[helenesanche]

Hey @AnsonHwang86 @bobmhong @tapnair thank you so much for your interest in this feature. I'm Hélène the Product Manager for Neo4j GraphQL library. Despite not being able to give you an exact timeline for when we'll be able to implement this, I can ensure you it's in the pipeline of our next priorities. Stay tuned ;)

[steffenkoenig]

Is there an update on this?
Also while not available as an auto generated mutation is there a good practice workaround?

[mobsean]

Why ist nobody talking about this?

In my perspective, this is a major feature and while it´s not implemented we can not migrate to @neo4j/graphql.

@darrellwarde Can you tell us, when or if there are any plans implenting MERGE?

[bobmhong]

@darrellwarde Wondering if you're able to provide a rough timeline when generated MERGE mutations could be addressed?

Does it help if the implementation uses the suggestion provided by @mobsean

Maybe this will work:
a MERGE mutation will only be generated if atleast one @unique field ist defined in typeDefs.

[angrykoala]

Hi @AnsonHwang86
I like this idea, we will be evaluating different approaches for this shortly.
Sorry for taking this long to give an update on this 🙏

[darrellwarde]

Why ist nobody talking about this?

In my perspective, this is a major feature and while it´s not implemented we can not migrate to @neo4j/graphql.

@darrellwarde Can you tell us, when or if there are any plans implenting MERGE?

It'll definitely get done, but there is no timeline yet.

At the moment we're looking at aggregations and interface relationship fields - they were prioritised as more important based on community and customer feedback.

[mobsean]

Thanks for the detailed answers.
I´m happy to hear that you have plans to implement MERGE.
And I´m also with you that you have to have an Unique Field (btw. related issue: #206).

In the old implementation the first field in the typeDefinition was automatically unique, this was very bad documented and I fell for this quite badly.

Maybe this will work:
a MERGE mutation will only be generated if atleast one @unique field ist defined in typeDefs.

[rcbevans]

I'm working on a system for our datamodel which required idempotent insertion of data and had to hand write all the upsert mutations by hand. It's not a huge deal, but would certainly be nice if there was merge/upsert mutations that could be generated.

[AnsonHwang86]

If nested upsert mutation would be supported, that is great.
Variables

{
  "upsert": [{
    "id":"a34-34534-sa3s-ee23",
    "firstName": "John"
    "lastName": "Luang",
    "posts":{
        "id":"s3d-s3353-asdf-fe34",
        "title": "post title",
        "comments":{
            ...
        }
     }
  }]
}```

[MacondoExpress]

We're planning to investigate more on this feature request in the near future given the popularity that has reached. I'll keep you sorted!

[angrykoala]

We've working on a draft proposal for supporting MERGE operations by implementing upsert mutations. Here is an early example of how these mutations would look like:

mutation {
  upsertMovies(input: [{
    node: {
      title: "The Matrix"
    },
    onCreate: {
      stars: 0
    },
    onUpdate: {
      released: 1999
    }
  }]) { title }
}

This would map to a MERGE in Cypher:

MERGE (m:Movie {title: "The Matrix"})
ON CREATE SET
  m.stars = 0
ON MATCH SET
  m.released = 1999

[danstarns]

I would like to chime in and mention that we left MERGE out for a few reasons; firstly, you need to MERGE on two unique fields and so that implies that nodes must have an id field, or something unique - something we don't enforce and then secondly, we couldn't find a nice way to get it to work with nested mutations. Finally, we found the mechanics of MERGE hard to reason about especially for your average GraphQL developer with less experience with Neo4j.

Of course, this doesn't negate the importance of MERGE, and in imparticular if you want to perform an atomic transaction.

Your ideas and suggestions are welcome here.

[tapnair]

This would be fantastic, but to your earlier comment it would be particularly valuable if it works relatively seamlessly with nested mutations/queries.

[AnsonHwang86]

waiting for this inplement

[AnsonHwang86]

Hello, I suggest to use name of upsert instead of merge.

upsert - Wiktionaryhttps://en.wiktionary.org › wiki › upsert
(computing, databases) An operation that inserts rows into a database table if they do not already exist, or updates them if they do

merge seen to be famiared to cypher user only.

Also please support upsert in batch(Array, many records) instead of object(one record).

type User{
   id: ID @id
   firstName: String
   lastName: String
   username: String @unique
}
mutation upsert($upsert: UserUpsertInput){
   upsertUsers (upsert: $upsert){
      users {
         id
         firstName
         lastName
      }
   }
}

**Variables**

{
  "upsert": [{
    "id":"a34-34534-sa3s-ee23",
    "firstName": "John"
    "lastName": "Luang"
//if the same id existed, this record will be updated, other wise will be created(the id field will be give up and be autogenerated, because of @id directive).
  },{
    "firstName": "Sophia",
    "lastName": "Qion",
    "username": "sophiaqion"
//if the same username existed, this record will be updated, other wise will be created.
  },{
    "id":"",
    "firstName": "Lan",
    "lastName": "He"
//this rocord will be created, because there is not id offered or unique field offered.
  }]
}```

[AnsonHwang86]

any update?