Increment/Decrement mutations

[dsbert]

Add the ability to atomically increment/decrement a value by a specified amount.

[kbrandwijk]

Would be covered (mostly) by https://github.com/graphcool/feature-requests/issues/262. If you have the previous value in TRANSFORM_ARGUMENT, you can also increment/decrement that value.

[dsbert]

That could work, but it isn't very intuitive to the client.

[kbrandwijk]

I agree, in that case either a custom mutation (https://github.com/graphcool/feature-requests/issues/40) that you can create yourself would work.

Or an autogenerated increaseTypeField or decreaseTypeField for all Int and Float fields would be nice. So if you have a type Score with an Int field value, the system could autogenerate a IncreaseScoreValue mutation.

Another option would be a certain syntax on the mutation arguments:
mutation { updateScore(id: "c......", value: { increase: 20 }) { ... } } or delta or relative, and possibly absolute : 20 to set the value instead of increasing/decreasing it.

Just coming up with a few concrete implementation options, to get this implemented sooner. Please comment on what you think would be the best way to implement this.

[dsbert]

I see this was already suggested . A custom mutation seems to fit better semantically with the idea of a mutation representing a type of action. I would also guess that the use case for this is limited enough that it shouldn't be needed on every automatically generated mutation.

[kbrandwijk]

I agree with a mutation being better than the parameter syntax. And as soon as custom mutations are available, you can do this. However, in the long run, I feel a checkbox on the Type field 'generate increase/decrease mutations' would be nice, since it's a pretty common use case.

[Plinpod]

Would also love to see this. Need it for multiple use cases.

[jtmthf]

I feel like this feature is still needed in the core CRUD api. As increment actions are a special type of mutation that is dependent on the current state of the database, ACID transactions can't be guaranteed right now.

For the time being I'm handling increment actions in a resolver function, but there is a several hundred ms, delay between querying the current state, and persisting the incremented value. With this setup simultaneous increment actions are lost.

Unless there is some other way to ensure a transaction lock between a query and a mutation, I don't see another way to do this outside of having it in core.

[Doeke]

Transactions would be useful! In the mean time I have some other ideas:

If you're counting things or events, you can model it as a relation, then query _relationMeta { count }.

If you don't need exact count but expect simultaneous operations, you can use probability. For example you count only 1 in 100 events, but multiply them by 100, so the end result is an approximation.

[roycclu]

@marktani
When will this feature be implemented? Multiple use cases (any counter function) for incremental increase or decrease.

[sorenbs]

We will implement this as atomic operations as described in #1349