Facets format in mutation requests and query responses

Users Dgraph
8

tl;dr; Solution #3

My code heavily relies on facets on edges working like they did in 1.1.0, and I’d like to upgrade :stuck_out_tongue:

Scalar list format

I don’t currently use scalar lists, however I strongly agree on the updated mutation format, that solution #3 brings (ignoring the facet response for now).

When looking at this mutation:

{
  "set": [
    {
      "uid": "_:1",
      "nickname": "Joshua"
    },
    {
      "uid": "_:1",
      "nickname": "David"
    }
  ]
}

I would obviously expect the second node to overwrite the first one, since this is how it works with uid nodes. Having Scalar Lists have a “list mutation” format:

{
  "set": [
    {
      "uid": "_:1",
      "nickname": ["Joshua"]
    },
    {
      "uid": "_:1",
      "nickname": ["David"]
    }
  ]
}

seems good to me, as it allows to see at first glance, that it adds to a list.
I understand, that list delete mutations would also change. Currently deletion:

{
   "uid": "0xd", #UID of the list.
   "testList": "Apple"
}

New delete format for scalar lists:

{
   "uid": "0xd", #UID of the list.
   "testList": ["Apple"]
}

Do I understand correctly?

Scalar list facets

I like the way it is solved in solution #3. I think this topic was exhausted in issue #4081, which arrived at the current format for scalar list facets.

However I would just like to digress and say, that representing scalar lists the same way as edges/uid-lists would be one solution to the problem, albeit a bit hacky one:

{
  "name": [
    {
      "name": "Alice Smith",
      "since": "1990-01-01"
    },
    {
      "name": "Alice Baker",
      "since": "2019-01-01"
    }
  ]
}

Mutation would look like this:

{
  "set": [
  {
    "uid": "_:1",
    "name": [
      {
        "name": "Alice Smith",
        "since": "1990-01-01"
      }
    ]
  },
  {
    "uid": "_:1",
    "name": [
      {
        "name": "Alice Baker",
        "since": "2019-01-01"
      }
    ]
  }
  ]
}

Now that I look at it, it could cause confusion if it’s actually an edge or not. The mutation parser would also not know this, when using dgraph as schemaless. However in that case, why have scalar list facets at all and not represent them as nodes, with all the power that it gives us… Modeling it as nodes would also solve the problem of the person that MichelDiz mentioned a few posts up.