rnewson commented on issue #2015: parse_revid - Badarg error in HTTP request URL: https://github.com/apache/couchdb/issues/2015#issuecomment-487293832 I still think the decoding as integer is about memory usage in the erlang runtime system. We "know" we can decode revs of that length to a number because we created them. A rev value itself has no meaning, it's only for comparison at update time. The deterministic rev system confuses matters by adding a meaning to gain an advantage (the same update to two separate couchdb systems generate the same new _rev, so that replication between them later does not create a conflict). I've invited others to comment (and obviously this thread is public) but my view at present is that we should not remove the '== 32' clauses or add a fallback if those don't decode correctly. At most, I suggest we add a line in the docs that user-generated rev values are discouraged and a stipulation that if those values are exactly 32 characters long they are required to be encoded integers. The determining factor here will be whatever we are going to define for CouchDB 4.0. If we're support custom _rev values in that release, we will have to provide documentation on what rules apply (maximum/minimum length, allowed characters, etc) and then, as you've requested, we'll consider any rev value that doesn't follow those rules as an error and reject them, with a readable error message.
---------------------------------------------------------------- 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: [email protected] With regards, Apache Git Services
