Feature Request: Increment/Decrement field values like Firestore

[Juri]

https://firebase.google.com/docs/firestore/manage-data/add-data#increment_a_numeric_value

Hi, I don’t understand why dgraph still has no increment/decrement feature :(( We need that feature buddies

Unfortunately upserts ain’t a solution, because if 1000 users like within one second a picture, dgraph can’t keep up with that and the transactions will fail

thank you very much!!!

[iluminae (Kenan Kessler)]

In a MVCC architecture like dgraphs, not sure how one would increment without following a read then write transaction which can fail. Any suggestions?

If it does not require 100% accuracy a separate read then a blind write would not fail but if two happen at once they would lose one increment value.

[jdgamble555 (Jonathan Gamble)]

Firestore works differently as counters pretty much don’t exist, so IMHO they are not comparable.

I see two options.

1. Use a custom lambda with DQL with an upsert:

Increment/Decrement across a set of nodes?

Why? This is a sum, not a “concatenate”. Sorry, copy/paste/edit error. Fixed it in my question. Why this cond? There’s no need for this unless I was just copying @dmai upsert example exactly as provided. I don’t know why he used it. Nonetheless, the results stayed the same as the original and the upsert did not increment the count.val as the @dmai stated it should. Not sure what I missed here. I can retry again after a little while to see if I had another typo somewhere in my code. T…

2. Create a new node for each count, then aggregate the total.

Ex. The number of likes on a posts:

type Post {
  id: ID!
  likes: [Like] @hasInverse(field: post)
  ...
}
type User {
  id: ID!
  likedPosts: [Like] @hasInverse(field: user)
  ...
}
type Like {
  id: string @id
  user: User
  post: Post
}

The like id will be a composite key like user__post to enforce uniqueness. I would also put this in a custom mutation until dgraph supports composite indexes and lambda pre-hooks in about 5 years.

This way, when you remove a like, add a like etc, the aggregate count will always be up-to-date. Increments can be fishy sometimes.

J

[Juri]

Hi thanks for the response

First solution would still have problems if 999 users like something at the same time. Right? (because 998 mutations/transactions would fail)
Or am I missing something?

Second solution: With that solution, to get the total like count, I would have to aggregate/count it every time i request it. is that right?

With the sentence:

@jdgamble555

This way, when you remove a like, add a like etc, the aggregate count will always be up-to-date. Increments can be fishy sometimes.

you mean that it will up-to-date, with the composite index & pre-hooks features in 5 years?

Or already now? How? With a ‘custom mutation’? What exactly do you mean with that?

[jdgamble555 (Jonathan Gamble)]

@Juri

First solution would still have problems if 999 users like something at the same time.

I am not sure, as definitely not an expert on how Dgraph works behind the scenes.

@Juri

With that solution, to get the total like count, I would have to aggregate/count it every time i request it. is that right?

Correct, but because Dgraph uses sharding, I don’t believe this would be a problem.

I think Dgraph is meant to be scalable in either case, but not an expert on Badger.

@Juri

features in 5 years?

I was being sarcastic here since we have to beg for any kind of communication or update from the Dgraph team.

That being said, I am a huge fan of the product.

J