Support for optimistic locking

[benjcooley]

.NET and Java DynamoDB sdk support optimistic locking using conditional constrainst and a special annotated numeric 'version' field in the schema.

This could be implemented in dynamoose via uuid and a tagged 'version' field in the schema.

_version: {
  version: true,  // This indicates this field is the version number field
  type: Number
  required: true
}

Whenever a record is updated and the '_version' field is passed, dynamoose will automatically add a conditional constraint to ensure the write only succeeds if the _version field matches.

Would be happy to implement and send a PR. Also would be happy to make this a plugin if there were a plugin interface.

[brandongoode]

A PR would be great. The feature will be very useful. Thanks.

[dolsem]

I would like to help with this. Suppose we add a boolean schema option optimisticLocking and when it's true we maintain a field called '_version'. Should this field be exposed to the user? If yes, should it just be a slightly special attribute like timestamps, which the user can manipulate and write custom definition for? Personally I think we should probably just hide it completely. Can't think of any reason to expose it.

[fishcharlie]

@dolsem I see the purpose of Dynamoose to be to make it easier to use DynamoDB and functionality like this. I don't see any reason to expose complexity unless there is a good reason for it. That being said, it might be beneficial for advanced or strange use cases to optionally expose it. But only if the developer wants to take advantage of it. Not sure if that would be more complicated to build in tho.

I see the value of making this part of Dynamoose itself, and I could be wrong, but I think there was some discussion about writing a Dynamoose plugin for this, and not implementing it into the library itself. #325

[dolsem]

@fishcharlie well I can do either, so let me know what makes most sense to you. Personally I view it as a core feature, because databases are often accessed concurrently, and there needs to be a way to ensure concurrent writes work correctly. However, if you think it's best to make it into a plugin, I can do that, no problem.

[fishcharlie]

@dolsem Part of me wants to say that we need testing of that plugins PR. BUT I think integrating it directly into Dynamoose is the correct path to take in my opinion.

[dolsem]

@fishcharlie I'm a bit confused: by direct integration you mean not choosing the plugin path, right? Then how's testing of the plugins PR relevant to this context? Or are you saying, ideally it should be a plugin, but only given the plugins PR has no issues and can be merged?

[fishcharlie]

@dolsem Sorry for the confusion. It should be implemented directly into this repository and codebase. Not as a plugin.

The only benefit I see to going down the plugins route is that it would give us more testing of that system. Which isn't enough of a benefit to go down that path in my opinion.

Feel free to work on this and submit a PR if you want 😃

[dolsem]

Okay, got it.

[fishcharlie]

@dolsem Actually I changed my mind on this. Unless someone has a strong case for being in Dynamoose directly, I think a plugin would be best suited for this task.

I'm closing this issue and moving it to the plugin ideas repo.

dynamoose/dynamoose-plugin-ideas#3

[ramharsha-pe]

@fishcharlie In cases of concurrency where multiple servers have to update a record and atomic updates are not an option Optimistic Lock Control feature can be of great help.

for eg. lets say I have to update the average cancelled orders of a product id every time somebody cancels an order with a productid, we will have multiple servers performing the same calculation and end up with botched records.