[jira] [Commented] (COUCHDB-769) Store large attachments external to the .couch file
[
https://issues.apache.org/jira/browse/COUCHDB-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15087085#comment-15087085
]
ASF GitHub Bot commented on COUCHDB-769:
Github user gilv commented on the pull request:
https://github.com/apache/couchdb-chttpd/pull/82#issuecomment-169601987
@kxepal I need your advice on the following:
Consider the following use case:
1. Attachment is stored externally
2. User download attachment
3. CouchDB fails to download attachment from Swift ( for example network
failure )
The relevant code in "chttpd_db" is:
ExtStoreID = couch_att:fetch(att_extstore_id,TmpAtt),
case ExtStoreID of
undefined ->
couch_log:debug("chttpd_db: Att is not stored in the
external store ~p~n",[ExtStoreID]),
Att = TmpAtt;
_ ->
Att = fabric_att_handler:att_get(Db, TmpAtt),
couch_log:debug("chtttpd_db: Got attachment from the
external store ~p~n",[ExtStoreID])
end,
My question is: what is the best way to handle this?
Should i do something like this:
case fabric_att_handler:att_get(Db, TmpAtt),
{ok, Att} ->
couch_log:debug("chtttpd_db: Got attachment from the
external store ~p~n",[ExtStoreID])
{error,_} ->
throw({
bad_request,
"Please try again later"
})
.
> Store large attachments external to the .couch file
> ---
>
> Key: COUCHDB-769
> URL: https://issues.apache.org/jira/browse/COUCHDB-769
> Project: CouchDB
> Issue Type: New Feature
> Components: Database Core
>Reporter: Robert Newson
>Assignee: Adam Kocoloski
> Attachments: external_attachments_alpha.patch
>
>
> For attachment-heavy applications storing the attachments in separate files
> significantly eases compaction problems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-769) Store large attachments external to the .couch file
[ https://issues.apache.org/jira/browse/COUCHDB-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15087160#comment-15087160 ] ASF GitHub Bot commented on COUCHDB-769: Github user kxepal commented on the pull request: https://github.com/apache/couchdb-chttpd/pull/82#issuecomment-169617505 @gilv It's not a bad request since it's not a user fault that Swift is down. HTTP 503 or HTTP 502 looks good here. But yes, the only thing you can do is to fail and throw error back. Btw, what's the timeout you use for fetching remote attachments? Do you stream response from Swift or buffer it in memory before return back to user? > Store large attachments external to the .couch file > --- > > Key: COUCHDB-769 > URL: https://issues.apache.org/jira/browse/COUCHDB-769 > Project: CouchDB > Issue Type: New Feature > Components: Database Core >Reporter: Robert Newson >Assignee: Adam Kocoloski > Attachments: external_attachments_alpha.patch > > > For attachment-heavy applications storing the attachments in separate files > significantly eases compaction problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] couchdb-fauxton pull request: remove useless grunt defaults
Github user benkeen commented on the pull request: https://github.com/apache/couchdb-fauxton/pull/598#issuecomment-169751605 True, this chunk of code isn't being used, but I disagree it's useless. We always override it, true, but it looks like we don't need to for Fauxton, no? (i.e. we could rely on the development or production defaults to take care of providing those default values). But besides that, I kind of like being able to see at a glance exactly what info grunt it looking for to create the build. Instead, in addition to dropping the code like you've done, could we add a validation check to ensure the required params are there: src, dest, and the required vars? That could output a nice juicy "such and such is missing" error to ensure grunt gets what it wants. I realize this isn't strictly needed now, but for people editing / creating new settings files it may be helpful. --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] couchdb-fauxton pull request: Table view: add prioritized table vi...
Github user justin-mcdavid-ibm commented on the pull request: https://github.com/apache/couchdb-fauxton/pull/580#issuecomment-169812572 Looks great, Robert. The only thing that we might tweak is some sort of even distribution across the footer for: Showing document X of X. (Keep left-justification) Showing X of X columns. [] Show all Columns Documents per page: X (Keep right-justification) --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (COUCHDB-2932) View query crashes if the emited key contains hidden characters
ILYA created COUCHDB-2932: - Summary: View query crashes if the emited key contains hidden characters Key: COUCHDB-2932 URL: https://issues.apache.org/jira/browse/COUCHDB-2932 Project: CouchDB Issue Type: Bug Reporter: ILYA In the cases where map function of the view emits invisible characters such as U+200B. Subsequent query of the view with the keys not containing invisible characters returns `badarg`. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2932) View query crashes if the emited key contains hidden characters
[ https://issues.apache.org/jira/browse/COUCHDB-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088289#comment-15088289 ] ILYA commented on COUCHDB-2932: --- Backtrace is [error] req_err(4004602127) unknown_error : badarg [<<"dict:fetch/2 L130">>,<<"fabric_view_map:-merge_row/4-fun-2-/3 L163">>, <<"lists:fmerge2_1/5 L2619">>,<<"lists:merge/3 L983">>, <<"fabric_view_map:handle_message/3 L143">>, <<"rexi_utils:process_mailbox/6 L55">>,<<"fabric_view_map:go/5 L73">>, <<"fabric_view_map:go/6 L39">>] This is happening because KeyDict contains keys without extra hidden chars https://github.com/apache/couchdb-fabric/blob/master/src/fabric_view_map.erl#L163 > View query crashes if the emited key contains hidden characters > --- > > Key: COUCHDB-2932 > URL: https://issues.apache.org/jira/browse/COUCHDB-2932 > Project: CouchDB > Issue Type: Bug >Reporter: ILYA > Attachments: invisible_char.sh > > > In the cases where map function of the view emits invisible characters such > as U+200B. Subsequent query of the view with the keys not containing > invisible characters returns `badarg`. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2932) View query crashes if the emited key contains hidden characters
[ https://issues.apache.org/jira/browse/COUCHDB-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088300#comment-15088300 ] ILYA commented on COUCHDB-2932: --- The workaround is to avoid inserting hidden characters into view. For example like this: emit([doc.title.replace(/[\u200B]/g, ''), doc.name.replace(/[\u200B]/g, '') > View query crashes if the emited key contains hidden characters > --- > > Key: COUCHDB-2932 > URL: https://issues.apache.org/jira/browse/COUCHDB-2932 > Project: CouchDB > Issue Type: Bug > Components: View Server Support >Reporter: ILYA > Labels: regression > Fix For: 2.0.0 > > Attachments: invisible_char.sh > > > In the cases where map function of the view emits invisible characters such > as U+200B. Subsequent query of the view with the keys not containing > invisible characters returns `badarg`. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
