Optimistic locking support

[hgrubst]

Question

Hi, after looking through the docs and code, I believe thinky does not support optimistic locking out of the box but I though I would still ask the question just in case I missed something.
The feature I am looking for is something as described here : rethinkdb/rethinkdb#5286 or even in the rethinkdb official docs here : https://rethinkdb.com/docs/consistency/ (under Linearizability and atomicity guarantees)

Basically the ability to add a field that would be checked prior to updating a document to be sure no other update has been performed between the moment we retrieved the document and wish to save it again.

The technique described here rethinkdb/rethinkdb#5286 would work fine. The only difference is that thinky does a replace when calling save (as opposed to update in the example) although it still works as expected.

What would be nice would be the ability to define the field that should be checked in the schema (if any). In the java world and hibernate, they use an annotation @Version to define such fields and the frameworks takes care of checking and incrementing that field automatically.

[neumino]

You can do the same thing as in rethinkdb/rethinkdb#5286 with replace. Thinky doesn't provide a special API to do that though.

[cur3n4]

I have created a very crude implementation in #588. Besides the lack of tests and so on, this could be extended by providing a type (date, string, number) for the optimistic locking field. @neumino Would you accept a proper PR to include something like this into the library?

[hgrubst]

Sorry for the late reply, @neumino I agree you can use that approach, which works very well. The point of using a framework like thinky is to give you that layer of abstraction on top of the db to free you from some of the lower level APIs. Being able to call save on your document and have the check hapening transparently would make things so much easier. It's also a important feature in its own and would give thinky even more added value over a driver closer to the db.
Thanks @cur3n4 for the PR, this is very close to what I had tested and works nice. Also good that you have to opt in to avoid any disruption to previous versions.