I looked into this issue and it looks like the problem is that the key is never rolled up. During a rollup, all the deltas for the affected keys would be compacted into one list that contains the new complete list. When this list is written the previous versions are discarded.
The problem is that right now Dgraph only rolls up lists as they are queried. So my guess is that you keep inserting data into this key but the list is not queried so it’s not being put into the list for rollups.
Internally, we will change Dgraph to also queue lists for rollups during mutations.
For now, you can do two things.
-
Use upsert to insert the
dgraph.typetriples. In the query part of the upsert, check if the type is already there and don’t insert the triple if that’s the case (I am assuming the type is always the same). -
Force a rollup. Try to query the specific list (I show an example below) to get this query into the queue. Keep in mind that this might require sending a lot of queries in quick succession to force the queues to fill quickly. Another tip is to send other queries along with this query to add more keys into the queue.
If you are starting from scratch with a new live load, you don’t need to do step 2. If you are using the live loader you can’t really use upserts. What you could do is removing the type triples from the initial live load, then figure out the types for each node, and start another live load that sets the types of the nodes only once.
What you want to avoid is getting into another situation where you are writing the data to the same node but never querying the node.
query to touch the types:
If you want to query a specific node.
{ q(func: uid(<uid of the node>)) { dgraph.type } }
If you want to query all the nodes of a specific type:
{ q(func: eq(dgraph.type, <name of your type>)) { dgraph.type } }