The 'timestamp in filename' is only on the internal shards, which would not be part of a replication between 2.x/3.x and 4.x.
In any case, Nick is suggesting lowering from 256 charts to 238 chars to leave room for these things that won't be there. I confess I don't understand the reasoning. B. > On 4 May 2020, at 20:04, Joan Touzet <woh...@apache.org> wrote: > > I suspect he means when replicating back to a 3.x or 2.x cluster. > > On 2020-05-04 3:03 p.m., Robert Samuel Newson wrote: >> But we don't need to add a file extension or a timestamp to database names. >> B. >>> On 4 May 2020, at 18:42, Nick Vatamaniuc <vatam...@gmail.com> wrote: >>> >>> Hello everyone, >>> >>> Good idea, +1 with one minor tweak: database name length in versions >>> <4.0 was restricted by the maximum file name on whatever file system >>> the server was running on. In practice that was 255, then there is an >>> extension and a timestamp in the filename which made the db name limit >>> be 238 so I suggest to use that instead. >>> >>> -Nick >>> >>> On Mon, May 4, 2020 at 11:51 AM Robert Samuel Newson <rnew...@apache.org> >>> wrote: >>>> >>>> Hi, >>>> >>>> I think I speak for many in accepting the risk that we're excluding doc >>>> ids formed from 4096-bit RSA signatures. >>>> >>>> I don't think I made it clear but I think these should be fixed limits >>>> (i.e, not configurable) in order to ensure inter-replication between >>>> couchdb installations wherever they are. >>>> >>>> B. >>>> >>>>> On 4 May 2020, at 10:52, Ilya Khlopotov <iil...@apache.org> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Thank you Robert for starting this important discussion. I think that the >>>>> values you propose make sense. >>>>> I can see a case when user would use hashes as document ids. All existent >>>>> hash functions I am aware of should return data which fit into 512 >>>>> characters. There is only one case which doesn't fit into 512 limit. If >>>>> user would decide to use RSA signatures as document ids and they use 4096 >>>>> bytes sized keys the signature size would be 684 bytes. >>>>> >>>>> However in this case users can easily replace signatures with hashes of >>>>> signatures. So I wouldn't worry about it to much. 512 sounds plenty to me. >>>>> >>>>> +1 to set hard limits on db name size and doc id size with proposed >>>>> values. >>>>> >>>>> Best regards, >>>>> iilyak >>>>> >>>>> On 2020/05/01 18:36:45, Robert Samuel Newson <rnew...@apache.org> wrote: >>>>>> Hello, >>>>>> >>>>>> There are other threads related to doc size (etc) limits for CouchDB >>>>>> 4.0, motivated by restrictions in FoundationDB, but we haven't discussed >>>>>> database name length and doc id length limits. These are encoded into >>>>>> FoundationDB keys and so we would be wise to forcibly limit their length >>>>>> from the start. >>>>>> >>>>>> I propose 256 character limit for database name and 512 character limit >>>>>> for doc ids. >>>>>> >>>>>> If you can't uniquely identify your database or document within those >>>>>> limits I argue that you're doing something wrong, and the limits here, >>>>>> while making FDB happy, are an aid to sensible application design. >>>>>> >>>>>> Does anyone want higher or lower limits? Comments pls. >>>>>> >>>>>> B. >>>>>> >>>>>> >>>>
