couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Vatamaniuc <vatam...@gmail.com>
Subject Re: [DISCUSS] length restrictions in 4.0
Date Mon, 04 May 2020 19:41:37 GMT
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 <rnewson@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 <wohali@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 <vatamane@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 <rnewson@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 <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