[GitHub] [couchdb] rjharmon edited a comment on issue #2015: parse_revid - Badarg error in HTTP request

[GitBox <gi...@apache.org>]

rjharmon edited a comment on issue #2015:
URL: https://github.com/apache/couchdb/issues/2015#issuecomment-649783342


   As a developer who uses it, I selected couchdb in part because the _rev is opaque and CAN be controlled from outside couchdb.   Using md5(erlang-data-representation) in those _revs is far from ideal for deterministic versioning, so it's not just a nice point of flexibility. But it is nice, for sure.
   
   Would push replicators from other versions/implementations (including and not limited to PouchDB) have to pull the new _rev and write it back to disk, when pushing to a server that ignores provided _rev's?  If so, that would be a minor ick.  
   
   Impact assessment: if one generates revs that have a 32-byte non-int, one would get an error, search and find this issue and then add or remove a byte from their _rev representation.  I'm not seeing that as "sharp", myself.  Did I miss something?
   
   I would suggest, as the simplest change, to continue the existing semantic of "support provided _rev's opaquely", while correcting the unintended ~~crash~~ahem, error-on-32-char-rev's-not-parsable.  I might also add any needed guidance for integrators and authors of custom replicators that they SHOULD generate deterministic _rev's if they use an algorithm different from couchdb's default internal mechanism.  
   
   Might it be helpful to strengthen any language for proxies and replication implementers to treat observed _rev's as opaque at baseline? while possibly noting that custom replicators are allowed to probe for any special meanings for some optimization purposes (just as the int-parsing logic does currently), but that they MUST be robust to opaque _rev's that don't fit their hopes and dreams.  I think that's another way of indicating the high-level outcome that it seems @ricellis drives at.
   
   @davisp It's possible to suggest people SHOULD NOT use flags in the revs for indicating such facts as deletion or update-times, although given that _rev's are opaque values, it's not clear to me that these bits of meaning even **could** be harmful to anyone (reminding myself that if one does such things, they can also evaluate and test against any potentially-colliding changes made in later releases of the server) - essentially as Paul said.  I'd leave off this bit, myself.  
   
   There's some additional perspective from the field.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org