couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: [DISCUSS] length restrictions in 4.0
Date Mon, 04 May 2020 15:51:35 GMT
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 <iilyak@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 <rnewson@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.
>> 
>> 


Mime
View raw message