Atomic Field Operations

Issues GraphQL
1

Hi,

is it currently possible to do atomic operations (e.g. atomic increment/decrement) on fields through GraphQL API? If so, how?

2

Not at the moment. Do you want me to convert this into a feature request? Could you explain some uses for it?

3

I converted this over to a feature request, I can give some use cases for this.

  • A voting system that needs to add one transactionally without record of who casts the vote

  • A simplistic social media use case where a post can have likes but liking users are not tracked, really just a deviant of the above.

  • A counter for IoT tool that tracks persons/things in and out. There are door greeters at stores counting heads in and out and an application in that manner would need to always be accurate between multiple doors. This is probably the most real use case atm.

    • There are 5 people in the store the greeters at the three doors and two customers
    • A person enters door A
    • A person enters door B
    • A person exits door C
    • Door A greeter gets current count (5)
    • Door B greeter gets current count (5)
    • Door C greeter gets current count (5)
    • Door A greeter adds one and sets count (6)
    • Door B greeter adds one and sets count (6)
    • Door C greeter subtracts one and sets count (4)
    • The count shows 4 but there are actually 6 heads.

References to support request:

In a single MySQL query, you can increment a value with

UPDATE store_counts
SET heads = heads + 1
WHERE store_id = ?
3 Likes
4

In MySQL it isn’t an atomic field operation. If there are two queries run at the same time, it may be trampled over

5

Normally, you do not need to lock tables, because all single UPDATE statements are atomic; no other session can interfere with any other currently executing SQL statement. However, there are a few cases when locking tables may provide an advantage…

You can avoid using LOCK TABLES in many cases by using relative updates (UPDATE customer SET value=value+new_value ) or the LAST_INSERT_ID() function.

^ Maybe I am missing something here because I am sleep deprived.

1 Like
6

Ah must be something new that I wasn’t aware of in MySQL (more of a Postgres guy when it comes to RDBMS)

1 Like
7

Normally such thing would be handled by an intermediate API layer. Which is easy to do and perfectly fine.

But my impression is that Dgraph GraphQL’s goal is to get rid of intermediate layers and expose the generated API directly to clients. Therefore, features like atomic operations or maybe a generic lock ability, would be very helpful in case multiple workers are accessing the database.