Connect in update mutation always merges existing relationship between current and connected node. There should be a possibility to create a new relationship (of the same type)

[magaton]

Hello, I think I hit a wall with mutation that should create a new relationship between 2 nodes, even if the same relationship type exists. I have a (c1:Client)-[:HAS_SPONSOR{startDate, type}]->(c2:Client) pattern in my model and I would like to create a new HAS_SPONSOR relationship between existing Client nodes, although THERE IS ALREADY A HAS_SPONSOR relationship between c1 and c2.

My graphql model definitely allows multiple outgoing HAS_SPONSOR relationships:

type Client {
   id: String!
   login: String!
   sponsor: [Client] @relationship(type: "HAS_SPONSOR", properties: "HasSponsor", direction: OUT)
   config: [Config] @relationship(type: "HAS_CONFIG", direction: OUT)
}

interface HasSponsor @relationshipProperties {
    type: String!
    startDate: Date!
    endDate: Date
}

My mutation (auto-generated) looks like this:

mutation UpdateClientsMutation($updateClientsWhere: ClientWhere, $updateClientsUpdate: ClientUpdateInput) {
  updateClients(where: {login: "x5", config: {store: "www.acme.com"}}, 
     update: {
       type: "Ambassador", 
       sponsor: {
         connect: {
           where: {
              node: { AND: [{login: "x2"}, {config: {store:"www.acme.com"}}]}
           },
           edge: {
                 type: "Ambassador",
                 startDate: "2022-04-15"
              }
         }
       }
     }) {
      
    clients {
      id
    }
  }
}

I can see in the console that the MERGE is executed on HAS_SPONSOR relationship, which results only in updated properties (startDate) and not in a completely new relationship, which I need.

[jbhurruth]

@angrykoala Is this being tracked as bug or other? I'd like to understand the behaviour a bit better since I want to rely on the existing behaviour and upsert edge properties via connect

[angrykoala]

Hi @jbhurruth Not as a bug, the merge is an expected behaviour as the main use case is to keep a single relationship between nodes, but it is tracked as a potential feature to add more flexibility for the described use case. You should have no problem relying on the existing behaviour

[to-kn]

@magaton since we are stuck at the same problem at the moment - did you find a possible workaround thats maybe worth sharing?

[magaton]

Not really. I had to change my model. In this case, I change the type of the existing relationship and create a new one through @neo4j/graphql

[to-kn]

Thank you @magaton! @darrellwarde is there any Timeline for this feature or are there any hints to maybe make this happen through eg custom mutations?

[darrellwarde]

Hey @to-kn, we have discussed this, and I think we need to consider whether we want to make a breaking change to "correct" the behaviour of connect. I have pencilled this in for our next major release, which we are working towards before the end of the year. I realise this is still a while off, but there's lots of work to go into it!

[magaton]

Hello, any update on this one?

[angrykoala]

Hi @magaton We have been discussing this and we started working towards this. The problem is that this breaks a lot of assumptions on how the library operates at the moment, as multiple relationships with the same type between 2 nodes are not really supported.

We want to support this, but a lot of thought needs to be put into this to avoid breaking other features so it is gonna be a while, and probably after a major release, as this will definitely be a breaking change.

[darrellwarde]

Hey @magaton, given your Mutation, you can now add an overwrite option:

mutation UpdateClientsMutation($updateClientsWhere: ClientWhere, $updateClientsUpdate: ClientUpdateInput) {
  updateClients(where: {login: "x5", config: {store: "www.acme.com"}}, 
     update: {
       type: "Ambassador", 
       sponsor: {
         connect: {
           where: {
              node: { AND: [{login: "x2"}, {config: {store:"www.acme.com"}}]}
           },
           edge: {
                 type: "Ambassador",
                 startDate: "2022-04-15"
              },
             overwrite: false
         }
       }
     }) {
      
    clients {
      id
    }
  }
}

This should give you the behaviour you're after! Probably in 5.0.0 (not 4.0.0), we will make this the default value.