I am studying Oracle SODA for using it as no-sql's document-store in my Java project.
Each collection is represented as an SQL table in the Oracle database. This table is composed by some fields like BLOB that contains the JSON payload, and VERSION field.
Can you give me some use cases in which are useful in the version field?
How can be used? Is it used for JSON versioning, or it's a private field managed by the database?
I am assuming you're looking at the Java implementation of SODA (since you mention you're doing a Java project).
The version component of each document is automatically maintained by SODA, and is used as an indicator that the document's content has changed. Anytime the document content changes (e.g. because of a replace operator), the version changes. One common way that's useful is for "optimistic locking": you can use the version to ensure that the document hasn't changed before you update or delete the document in your transaction. For example:
col.find().key("k1").version("123E...").replaceOneAndGet(...)
This will replace a document with key k1, but only if its version matches the provided hexadecimal version string (i.e. if another transaction updated the document since your transaction last read it, then its stored version wouldn't match the one supplied to the version(...) method, and the replace would not succeed).
How do you obtain the current version of the document? When you initially insert a document using insertAndGet(...), the returned result document will contain the automatically generated version for that document. If you successfully update the document using replaceOneAndGet(...), the returned result document will also have the updated version.
Version can also be used as an eTag if you're building a REST app.
There are different versioning methods available (these can be chosen at collection create time). See their description here. The appropriate method can be picked during collection creation.
Currently the default for an on-premises database is SHA256, but we're moving away from that toward UUID (it's cheaper to generate, and it doesn't block some optimizations that we want to do in the future). It's already the new default for SODA in some cloud environments (Autonomous Database cloud services). If you'd like more info on the pros and cons of different versioning methods, or how to configure a collection with these, please let me know. In general, we recommend going with UUID, unless there are strong reasons to pick another versioning method.
