From dev-return-49331-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Mon May 4 20:06:46 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 5AB79180608 for ; Mon, 4 May 2020 22:06:46 +0200 (CEST) Received: (qmail 80258 invoked by uid 500); 4 May 2020 20:06:45 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 80246 invoked by uid 99); 4 May 2020 20:06:45 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 May 2020 20:06:45 +0000 Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 38B0F8266 for ; Mon, 4 May 2020 20:06:45 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id ED46A27C005C for ; Mon, 4 May 2020 16:06:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 04 May 2020 16:06:44 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeeggddufeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfuffhfvfgjkffosehtqh hmtdhhtddvnecuhfhrohhmpeftohgsvghrthcuufgrmhhuvghlucfpvgifshhonhcuoehr nhgvfihsohhnsegrphgrtghhvgdrohhrgheqnecuggftrfgrthhtvghrnhepfeekjeffje evkeeitdekhfejteefuedtleefieekhedvjedvleeitefggeejjeefnecukfhppeekledr vdefkedrudehgedrvdegudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehrnhgvfihsohhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi thihqdelfeegvddtvdejvddqudduleegjedtjeejqdhrnhgvfihsohhnpeeprghprggthh gvrdhorhhgsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: from [10.66.10.6] (unknown [89.238.154.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 6FDE53280067 for ; Mon, 4 May 2020 16:06:44 -0400 (EDT) From: Robert Samuel Newson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [DISCUSS] length restrictions in 4.0 Date: Mon, 4 May 2020 21:06:42 +0100 References: <4627ABDC-A072-4029-B1EF-9DD72CAB61F6@apache.org> <139f9ab2-e5d2-cc8c-0426-95b912263117@apache.org> <7BC9C558-AD15-46E5-9B85-89E89D57D342@apache.org> To: CouchDB Developers In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Ah, ok, understood. I don't think that's a compelling reason to fix our = maximum database name length at 238. CouchDB 4.0 will be the first version of CouchDB where we're not coupled = to the filesystem for this list. 256 is very common for a filesystem = filename length limit (though not universal) so I don't think our = history should dictate an odd (fine, _even_) choice of 238. B. > On 4 May 2020, at 20:41, Nick Vatamaniuc wrote: >=20 > 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. >=20 > On Mon, May 4, 2020 at 3:15 PM Robert Samuel Newson = wrote: >>=20 >> 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. >>=20 >> 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. >>=20 >> B. >>=20 >>> On 4 May 2020, at 20:04, Joan Touzet wrote: >>>=20 >>> I suspect he means when replicating back to a 3.x or 2.x cluster. >>>=20 >>> 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 = wrote: >>>>>=20 >>>>> Hello everyone, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> -Nick >>>>>=20 >>>>> On Mon, May 4, 2020 at 11:51 AM Robert Samuel Newson = wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I think I speak for many in accepting the risk that we're = excluding doc ids formed from 4096-bit RSA signatures. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> B. >>>>>>=20 >>>>>>> On 4 May 2020, at 10:52, Ilya Khlopotov = wrote: >>>>>>>=20 >>>>>>> Hello, >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> +1 to set hard limits on db name size and doc id size with = proposed values. >>>>>>>=20 >>>>>>> Best regards, >>>>>>> iilyak >>>>>>>=20 >>>>>>> On 2020/05/01 18:36:45, Robert Samuel Newson = wrote: >>>>>>>> Hello, >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> I propose 256 character limit for database name and 512 = character limit for doc ids. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Does anyone want higher or lower limits? Comments pls. >>>>>>>>=20 >>>>>>>> B. >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>=20