Hi Joan,
> Point of order - when we do 72-hour votes, it's best to not count
weekends in that 72-hours.
I remembered the 72 hours is 72 so that everyone has an opportunity to
chime in regardless of their location / timezone. (Ie. so that there's
at least a fraction of a weekday included for
A belated +1.
Infinite attachment size is obviously an oversight, and practically
speaking, I think gigabyte sized attachments are still way too big.
I would love to see a solid binary attachment system with CouchDB, but
neither couch_file nor FDB are likely to be it.
-Russell
On Mon, Feb 1,
HI Donat,
Point of order - when we do 72-hour votes, it's best to not count
weekends in that 72-hours. So, since you started on the 28th at 05:00
UTC, I would have continued the vote until Feb 2 at 05:00 UTC.
That said I am +1 on this too, long overdue.
As to Eric's point, all we need to do is
This vote is now closed as there were three +1s, one +0 and no -1s and
the 72 hours is up. I'll merge the PR.
Thanks to all who voted!
Donat
On Mon, Feb 1, 2021 at 7:52 PM Eric Avdey wrote:
>
> Ok, fair enough, +0 from me with a note that I'd still prefer to see this
> limit aligned with
Ok, fair enough, +0 from me with a note that I'd still prefer to see this limit
aligned with 4.x limits, so users wouldn't have to adjust to this change twice.
Eric
> On Feb 1, 2021, at 14:47, Nick Vatamaniuc wrote:
>
> I am +1 to lowering as it's better than infinity.
>
> But I also see
I am +1 to lowering as it's better than infinity.
But I also see Eric's point. I was surprised a while back just like
Eric that I could successfully upload >1GB-sized files. So why not
0.5GB or 2GB? I am thinking 2GB was (is?) a common limit on some OSes
and file systems (FAT32) since they use
+1
Default unlimited seems like an oversight regardless of what we change it to.
On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey wrote:
>
> Maybe I didn't express myself clear enough. Setting some finit default is not
> a purpose, it's what you are doing and I'm asking what the reason for this
>
Maybe I didn't express myself clear enough. Setting some finit default is not a
purpose, it's what you are doing and I'm asking what the reason for this
change. In other words I'm not asking what are you doing, I'm asking why are
you doing this.
Introducing a new limit will be a breaking
The purpose of this vote / PR is to set _some_ finite default. I went
with 1G as I assumed that would not break anyone's production system.
I'd support decreasing that limit over time.
The vote has been open for 72 hours now, but I believe it still needs
two more +1s to pass.
Donat
On Thu, Jan
This got me curious and I tried to upload Ubuntu image as an attachment.
Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned
proper 201 response with a new doc revision, which I certanly didn't expect.
Should say, that 1.4G seems suspiciously similar to a normal memory
Hi,
I think a gigabyte is _very_ generous given our experience of this feature in
practice.
In 4.x attachment size will necessarily be much more restrictive, so it seems
prudent to move toward that limit.
I don’t think many folks (hopefully no one!) is routinely inserting attachments
over 1
There is no justification neither here or on the PR for this change, i.e. why
this is done. Original infinity default was set to preserve previous behaviour,
this change will inadvertently break workflow for users who upload large
attachment and haven't set explicit default, so why is it fine
+1
> On 28 Jan 2021, at 05:46, Bessenyei Balázs Donát wrote:
>
> Hi All,
>
> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
> finite default for max_attachment_size .
> The PR is approved, but as per Ilya's request, I'd like to call for a
> lazy majority vote here.
> The
Hi All,
In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
finite default for max_attachment_size .
The PR is approved, but as per Ilya's request, I'd like to call for a
lazy majority vote here.
The vote will remain open for at least 72 hours from now.
Please let me know if
14 matches
Mail list logo