Keep ._rev property on returned instance of model

[jannyHou]

A further discussion of #54 (comment)
Regarding

When I step back a bit and look at the problem from a high level perspective, then I think it should be acceptable to require callers of patch/replace operations to provide _rev in the data, as that's the way how CouchDB/Cloudant allows clients to detect and resolve conflicts

Our current implementation:
Now whenever rev is needed, eg: in function Cloudant.prototype.delete(), Cloudant.prototype.replaceById(), we call getCurrentRevision().
But considering the nature of Cloudant db, we should ask the caller to provide rev, and return error if it's missing.

Affected functions:

• updateOrCreate
  • PATCH Models/
  • Provide rev when updating an existed instance with data: {rev: rev_of_new_data}
• replaceOrCreate
  • PUT Models/
  • Provide rev when replacing an existed instance with data: {rev: rev_of_new_data}
• save
  • need to investigate
• replaceById
  • Provide rev when replacing an existed instance with data: {rev: rev_of_new_data}
• delete
  • DELETE Models/
  • We disabled this endpoint and DELETE Models/{id} doesn't accept data...any idea? Probably keep our current design.

[bajtos]

But considering the nature of Cloudant db, we should ask the caller to provide rev, and return error if it's missing.

A big +1 from me.

I believe the field is called _rev in Cloudant, isn't it? https://docs.cloudant.com/mvcc.html#revisions

I am proposing to define a _rev property on a model at the time when the model is attached to a Cloudant datasource. That way the _rev property will be propagated to Swagger too.

The catch is how to tell clients that _rev should not be included in create requests? This is similar to the problem of excluding id property when forceId is true, see strongloop/loopback#2924

[jannyHou]

@bajtos ah sorry I forgot to direct you to #54 (comment), I made some comment about how to let callers access _rev in that link.

The catch is how to tell clients that _rev should not be included in create requests

True, I will look into this part. My suggestion is based on using an option flag to tell function fromDB() returns _rev with data or not, so doesn't have this concern.