Is it possible to execute multiple upsert block within the same transaction?

Hey, probably a noob question but I’ll ask anyways :smiley:

Is it possible to execute multiple upsert block within the same transaction?
I have 3 entities, song, artist, album they are all related to each other

My first upsert is for the base entities, it is used for creating the basic entity(without the relations that I want)
My second upsert is used for creating the relations,

You might ask why don’t I just make it happen within a single upsert block,
Well I’ve tried but sadly this seems impossible because in the first upsert I’m trying to fetch a song/album/artist and if they don’t exist I create them, so as a result in the mutation I’m using a blank uid which I can’t refer to in other mutations

Am I doing something wrong? Just a general question, how did you learn dgraph? I like it but can’t really find any documentation other than the official one which lacks in some topics such as upserts

Kind of, yes.

So, I assume you wanna update them in one batch.

Humm, that’s what I thought.

You could combine with conditional Upserts.

Going back to this question. You could potentially have several upserts using the same transaction. But you have to learn how to manage a transaction You can have an idea here

All clients you can open a transaction, send several mutations, and finally commit them. That’s a way of doing this.

Should have probably noted, I’m already using transactions using the golang client.

Yes I want to update or add(if they don’t exist) in one batch (with the relations)
I’m already using conditional upserts in order to decide whether I need to add a new entity or just ignore the query,

  • 1 condition that checks whether the artist exists
  • 1 condition that checks whether the album exists
  • 1 condition that checks whether the song exist and if it exists I’m also checking if the song is connected to the same artist that is going to be add in the current batch (Used for adding multiple songs with the same name but different author)

Imagine having more conditions just for adding the relations, this will look like a huge mess
So I thought of a different approach, what if I’ll create the entities firstly and then in another upsert block I’ll just make the relations, seems like a more simple approach instead of adding tons of mutations to the same approach.

So here is my transaction:

  1. Start the transaction
  2. Upsert the basic entities
  3. Upsert the relations between the entities
  4. Commit the transaction

The problem is that during step 3 it seems like I don’t have the entities from step 2, should transactions work like that?

Thanks for the quick response!
Hopefully I’ll get to help somebody else with it in the future :slight_smile:

Oh, that makes sense. I never have tried this before. But maybe you could use fixed blank nodes.
e.g. You have created the entities with a blank node, like _:artist1, _:album1, _:song1.

In my belief, it should have the same UID for all of them as they are in the same transaction. Which shares context. So, on the other upserts, you can reuse the same blank node as a reference to the previous mutation in the same TXN. But your upserts must take into account the “if exist use the actual UID, not blank nodes”.

If you don’t get it or if it doesn’t work let me know.


Doesn’t work :confused:
it seems like it’s just creating a new node instead of editing the one that was created in the previous upsert of the same transaction

Can I somehow execute mutations in a specific order?

That seems like kind of a big deal anyways I’ll have to make 4 mutations for each entity
e.g: Artist → Album relation

  1. if artist && album
  2. if !artist && !album
  3. if !artist && album
  4. if artist && album

Seems like an overkill

I’m thinking about just commiting an upsert that creates the basic entities and then commiting an upsert that creates the relations between the entities, sadly this is not atomic but I’m just lost nothing works for me :frowning:

Thanks a lot for the help!
Didn’t have time to reply earlier :smiley:

Okay, I gonna investigate it. It should work, as the @upsert directive works in the transaction context. That would make life easier.

Well it works :smiley:
Took the long approach with the multiple mutations , 15 different mutation within 1 upsert hopefully it will be fine performance wise…

had another problem with transactions but that was a bug in my wrapper library :sweat_smile: