Dgraph: I have need for a way to store/filter/mutate an array<any>

[willcj33]

I would like to be able to store an array of whatever type (as a scalar) to a node. An example would be that I have an array of 3 datetimes and would like to be able to store them all to a similar edge "graduation_dates". I would like to be able to search if ANY graduation date is <= Today + 1 week and > Now. If any of them match that, I would like it to return the item (whatever properties I am querying for). I would also like to be able to update that list. Appending to it, or removing from it (based on the value of the item I am storing). So, If I had a string array ("nicknames"), I would like to be able to delete a specific nickname (maybe like delete "Nickname1" .) and have that updated the array. It would also be ideal to be able to do a len on these arrays.

So in summary, it would be nice to store an array (of whatever scalar type) and be able to perform full filtering on all of it's values as well as mutate specific items of the list or the list all together as well. If this functionality exists, I am unaware of it.

[lazharichir]

Exactly about to post the same feature idea / request.

Quick example:

mutation {
  set {
    _:0 <first_name> "Jack" . 
    _:0 <has_occupation> "dog breeder" .
    _:0 <has_occupation> "ceo" .
    _:0 <has_occupation> "philanthropist" .
  }
}

When querying:

{
  "me": [
    {
      "_uid_": "0x1e0",
      "first_name": "Jack",
      "has_occupation": "philanthropist"
    }
  ]
}

But it would be great to include a feature where we can add these instead of replacing them (here, it should return philanthropist, ceo, dog breeder, for example.)

Especially with Knowledge Graphs, often the same predicate applies several times with different values for the same node. And one should not replace the other but instead add to it.

[manishrjain]

We need to start supporting a list of values. @pawanrawal is looking into it.

[pawanrawal]

This should be easy given how we store our data internally in posting lists. The schema can be used to mention when a predicate should store a list of values ([string], [int]) and when a single value (present case).

@willcj33 @lazharichir Is the ordering of the items important when you want the whole list back? Even if we keep the order, a delete followed by a set would put the value at the end of the list.

The way I am thinking of implementing this is

1. You specify in the schema that a predicate should be a list of scalar values.

has_occupation: [string] @index(term) .

1. Set operation adds the value to the list if not already there. Delete deletes the value if its there in the list. No ordering is maintained.
2. Getting the predicate in the query returns an array of scalar values.
3. Filtering would be possible based on any value stored in the list.
4. Sorting won't be allowed by a predicate which stores a list of scalar values.
5. You can delete all the values using S P * deletion to clear the list. You can do sets after doing S P * to replace the list.

[lazharichir]

Thanks @pawanrawal - but is this also ok with UID predicates and not int/string as this is how I'll use them the most: <term> <defines> <topic_uid> (weight=...) or could be <person> <has_occupation> <occupation_uid> (from=DATE,to=DATE)

The order is not very important as generally with query the whole list back sorting by the predicate's value (weight, generally.)

[willcj33]

@pawanrawal

1. I like the way you have this, I would like to be able to get a len of the list as well, so maybe the @count could be used as well? As long as each item in the array respects the typical scalar filtering, I'm good with that.
2. Perfect.
3. Perfect again. What will be the limit to list size? (not that I will grow this list too long). If we need to though, could we page the list somehow?
4. Sounds good
5. 👍
6. Great!

[pawanrawal]

@lazharichir We already support this for UID predicates. In fact, that is how you would add friends to a person. E.g. (https://tour.dgraph.io/intro/3/). Did you mean something else? And as you mentioned, you can sort those by a facet weight or some other predicate.

@willcj33 Thanks for the feedback. Yes count(occupations) should work well. I will get started on this.

---

Update (21-08-2017)
We are not supporting paging the list for now.

[pawanrawal]

This feature is in master as of 1728afa703813e66ff620c5cc4bd4a5783e843bd.