Support for versioned optimistic locking a la DynamoDBMapper

[ezmuller]

Adds a new nullable version attribute type which initializes at 1 and increments on save/update for optimistic locking.

[ikonst]

@garrettheel @jpinner-lyft This is a pretty well-done contribution!

We have been traditionally rejecting new features that don't map somehow to core DynamoDB features, instead pointing authors at pynamodb-attributes. However, this feature wouldn't be possible through attributes alone, since it modifies Model.save etc. Also, a version/revision attribute is a common pattern, and I can see it being useful.

What do you think?

[garrettheel]

I'm supportive of putting this into the core given that this is such a common pattern. I took a quick first pass and it mostly looks good! I'll give it more of a look over the next few days.

Would love to see some docs with usage examples (especially exceptions) here too.

[ikonst]

Ahh, I somehow missed that this maps to a DynamoDBMapper feature.

[ikonst]

(On a side note, I'd love if we could add something like blinker signals so that such behaviors could be implemented by plugins.)

[ezmuller]

The more recent update modifies the behavior of save to update the local object i.e. can be called multiple times without needing to refresh. I implemented this in Model.save since https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html#DDB-PutItem-request-ReturnValues only supports ReturnValues of NONE or ALL_OLD.

I'll also update this later tonight for Transactions.

[ezmuller]

Would love to see some docs with usage examples (especially exceptions) here too.

I was thinking I would wait to add docs and examples until people are happy with what I've implemented, so that I only have do it once.

For exceptions it doesn't look like I can differentiate whether a condition check failed because of the version attribute or some other conditional expression, so there won't be anything interesting there. I'll be sure to add examples with exceptions when I get there though.

[ezmuller]

Rebased and squashed to a single commit.

[ikonst]

The squash-and-force-push workflow used to make it hard to track changes, but I just realized GitHub allows now to see the diffs between the force-push and the commit it replaced.

[ezmuller]

The squash-and-force-push workflow used to make it hard to track changes, but I just realized GitHub allows now to see the diffs between the force-push and the commit it replaced.

Still error-prone though. :D

[ezmuller]

@ikonst @garrettheel Any idea when you'll have time for another pass?

[garrettheel]

@ezmuller docs look good, thanks for writing those! I think this is pretty much ready to go, just a couple of final small comments

[ezmuller]

@ezmuller docs look good, thanks for writing those! I think this is pretty much ready to go, just a couple of final small comments

Np feature wouldn't be all that useful undocumented. Thanks for taking the time to go through all the revisions @garrettheel @ikonst !

[ezmuller]

Squashed

[garrettheel]

Thanks for all the effort here!