deal.
> On 12 May 2020, at 22:50, Nick Vatamaniuc wrote:
>
> Ok, fine, let's not worry about it the 238 limit then, I'll yield :-)
>
> But, if we are going by file system file name limits as a guide, in
> general, most of them are 255 not 256, so let's go with that.
>
>
Hi all,
When we introduced partitioned databases in 3.0 we declined to add a
partition-specific _changes endpoint, because we didn’t have a prebuilt index
that could support it. It sounds like the lack of that endpoint is a bit of a
drag. I wanted to start this thread to consider adding it.
Ok, fine, let's not worry about it the 238 limit then, I'll yield :-)
But, if we are going by file system file name limits as a guide, in
general, most of them are 255 not 256, so let's go with that.
https://en.wikipedia.org/wiki/Comparison_of_file_systems
On Tue, May 12, 2020 at 5:29 PM Robert
You'd have to replicate "back" and adjust the target db name to fit. It doesn't
feel like a terrible hardship.
> On 12 May 2020, at 21:54, Joan Touzet wrote:
>
> I presume the workaround would be "Replicate back to CouchDB 3.x, but
> truncate to 236 characters in the process?" You'd lose
I presume the workaround would be "Replicate back to CouchDB 3.x, but
truncate to 236 characters in the process?" You'd lose fidelity in the
db name that way.
-Joan
On 2020-05-12 4:05 p.m., Robert Newson wrote:
I still don’t understand how the internal shard database name format has any
Taking another swing at this.
The 238 choice would mean that any valid 4.0 db name can be replicated back to
<3.0 because, to succeed, those versions will make internal shard names that
exceed common filesystem lengths.
Fine, I accept that. Backward compatibility is a tricky balance.
My
I still don’t understand how the internal shard database name format has any
bearing on our public interface, present or future.
--
Robert Samuel Newson
rnew...@apache.org
On Tue, 12 May 2020, at 19:52, Nick Vatamaniuc wrote:
> I still like it. It's only 18 bytes difference but it
I still like it. It's only 18 bytes difference but it introduces one
more compatibility issue. At least for 4.x, it would be nice to have
less of those and we can always increase it later. But if other
participants think it's too nitpick-y and odd I am happy to go with
256.
-Nick
On Tue, May 12,
On 2020-05-12 5:46 a.m., Ilya Khlopotov wrote:
I would be +1 as long as it works and we have options to migrate archive
elsewhere if/when we need to.
You are proposing to mirror email traffic which means that mail archive would
have a complete history and spare the project from total vendor
I’d be willing to give this a go. +1 :)
Best
Jan
—
> On 11. May 2020, at 21:04, Joan Touzet wrote:
>
> On 2020-03-15 9:36, Dave Cottlehuber wrote:
>> On Fri, 13 Mar 2020, at 14:35, Naomi Slater wrote:
>>> apparently GitHub has discussions now. it's still in beta, but you can
>>> specifically
Sorry to let this thread drop.
Nick, are you still preferring 238?
B.
> On 4 May 2020, at 21:06, Robert Samuel Newson wrote:
>
> 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
I would be +1 as long as it works and we have options to migrate archive
elsewhere if/when we need to.
You are proposing to mirror email traffic which means that mail archive would
have a complete history and spare the project from total vendor lock in.
Best regards,
ILYA
On 2020/05/11
12 matches
Mail list logo
