It will prevent replicating from db created in 4.0 which has a name longer than 238 (say 250) back to 2.x/3.x if the user intends to keep the same database name on both systems, that's what I meant.
On Mon, May 4, 2020 at 3:15 PM Robert Samuel Newson <rnew...@apache.org> wrote: > > 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. > >>>>>> > >>>>>> > >>>> >
