rjharmon commented 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-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:
us...@infra.apache.org
