Github user kxepal commented on the pull request:
https://github.com/apache/couchdb-chttpd/pull/114#issuecomment-211124401
Hi Tony! Nice feature, but...
1. Why there is a need to introduce another configuration option instead of
reusing existed `max_document_size `? The case: I see in configuration options:
```
[couchdb]
max_document_size = 1048576
single_max_doc_size = 2097152
```
What the document max size will be actually allowed? I guess, without
code/experiment that would be hard to say for sure.
P.S. Yes, I know, that `max_document_size` applies for all the POST/PUT
requests, even for _config options. May be worth to fix that instead?
2. It seems like multipart requests are not handled. So the workaround of
this limitation would be a multipart requests. Moreover, this will lead to
quite strange cases. Assume we have ServerA and ServerB. ServerB limit
documents by 2MiB size. ServerA has a document of 3MiB size and we want to
replicate it. Because of the `single_max_doc_size` it won't, but we can add few
attachments into it and it will: replicator uses multipart requests if document
contains attachments for optimization reasons. So ServerA gets a document which
it cannot update. If you uses deletion with preserve content, even admins
cannot update such documents (but they should).
3. If server provides `_update` handlers, we still can create documents
over the limit and, actually, update them without triggering 413 error.
4. Default may be quite too low. In 1.x we had 2GiB `max_document_size`
which actually means "no limits". 1 MiB limit would be quite easily to hit and
that would be a surprise error since even MongoDB allows docs to be up to 16MiB.
5. Sadly, we cannot configure it per database. Common case is when a single
server is used for multiple applications. The goals of each are different as
like as the data they operate. We would love to set limit as low as possible
for public databases, but we have to respect needs of private ones. This makes
this feature use quite complicated and actually, painful.
Resume: this feature is good indeed and helps to keep our CouchDB in good
form, but the number of workaround and problems may not let users use it right.
How can we deal with them?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
