MichelDiz commented :
This is different, this is a bulk upsert. It is a set of multiple mutations aligned. That is, for each node found it will perform that mutation block as a “template”.
See, Dgraph iterates over its own Entities. But not in nested or even multiple values. And there is nothing that can dynamically generate multiple lines of RDF in the mutation block, or even create multiple mutation blocks based on the value/map (for example “user_data AS UNWIND”).
This type of interaction does not exist in Dgraph.
Take for example issue #4712 and #4779. In them I had to use an intermediate block so that I could pass a value from one node to the other. Without this block (me), the operation would not work. And if I do a Bulk upsert, the values will get messed up. This problem with aggregations also occurs in Queries of Facets (see #4160). Where to get accurate values I have to limit the query to 1 result at a time.
This problem happens with aggregations and also nested blocks.
The nested block is the key point to explain why it doesn’t work. In issue #4779 - without the intermediate block, I can’t get the values "title, released, tagline" (see the example in 4779 issue). And if I don’t limit it to 1 to 1 operation, the values get messed up, get mixed up and it will mess up with the DB.
That’s why I find your UNWIND proposal complicated. We need to solve other design problems first. These uses cases were never foreseen and Upsert Block is only a few months old.
As I said before, to start thinking about UNWIND. Some problems will need to be resolved:
1 - Support GraphQL Variables in Upsert Block.
2 - Have something similar to the custom block for hold/put the GraphQL Variables.
3 - We need to solve the issue of issue #4779 - allowing free use of variables and objects in the blocks regardless of level. Without having to use an intermediate block. This would be the case of the UNWIND map of objects.
3.1 - Maybe create a loop function like “for each”. If issue #4779 is not possible to resolve.