# IncrementAndGet Atomic Operation

**URL:** <https://forums.foundationdb.org/t/incrementandget-atomic-operation/2169>\
**Category:** Using FoundationDB\
**Tags:** performance\
**Created:** [June 8, 2020, 6:22am UTC](https://forums.foundationdb.org/t/incrementandget-atomic-operation/2169 "2020-06-08T06:22:40Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![subramaniamr](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/subramaniamr/32/658_2.png) [@subramaniamr](https://forums.foundationdb.org/u/subramaniamr)\
**Post date:** [June 8, 2020, 6:22am UTC](https://forums.foundationdb.org/t/incrementandget-atomic-operation/2169/1 "2020-06-08T06:22:41Z")

</div>

Is it possible to have an MutationType which will increment an number and also return the new value ? Any layer implementation which relies on a primary key feature will need this feature.

Current op that just Adds a value is not usable as a primary key generator as there is no reliable way to get the value which was just incremented. I understand that this operation will not be in scope of the existing transaction boundary as the incremented value cant be rolled back. But I think this is an acceptable scenario.

I read the High-Contention-Allocator algorithm but I dont think it fits the usecase.

---

<div class="post-metadata">

**Author:** ![ajbeamon](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ajbeamon/32/13_2.png) [@ajbeamon](https://forums.foundationdb.org/u/ajbeamon)\
**Post date:** [June 8, 2020, 3:28pm UTC](https://forums.foundationdb.org/t/incrementandget-atomic-operation/2169/2 "2020-06-08T15:28:10Z")

</div>

With respect to an `IncrementAndGet` op, it’s not possible to get the value immediately with a no-read atomic increment because the value will not be known until some (asynchronous) point after the commit. There has been a prior request to be able to access this value eventually when it is known, and you can see [https://github.com/apple/foundationdb/issues/627](https://github.com/apple/foundationdb/issues/627) for that discussion.

As to implementing a primary key, [versionstamps](https://apple.github.io/foundationdb/data-modeling.html#versionstamps) are likely to be helpful here. There’s some discussion on the above linked thread and various other forum posts about these as well, but the basic idea is that you can insert into your keys and values a versionstamp that will be replaced at commit time by a monotonically increasing unique value. You can use the same stamp in multiple places in the same transaction, and you can also inspect the value after the transaction commits.