Re: CouchDB Wiki / Documentation
On Mar 6, 2010, at 4:47 PM, Noah Slater wrote: On 7 Mar 2010, at 00:38, Mikeal Rogers wrote: We can provide the same providence and copyright assurances outside of JIRA. It's a checkbox, it's not hard. I agree. I don't want to be misunderstood as fighting against the initiative of improving our documentation. I just want to make sure we do it in a way that embraces our parent organisation. And as far as I know, and I am incorrect rather frequently, that involves hosting whatever we use on ASF infrastructure, and taking the proper measures to make sure that what is produced is free for the community to use, where free is the ASF's definition of free. If we can satisfy that, and improve our documentation, it will have my full support. However, just creating a new repository on Github and linking to it from our site is not satisfactory. I think the short run, putting together an informal Markdown repository of docs or proto-docs would be cool. I don't care where it live but we'll need to get an ASF Zone for a project CouchDB instance. I guess this means Damien has to send an email to infra. It's simple to have CouchDB render Markdown. After 0.11 is out and we launch the project CouchDB instance, I'm sure there are a ton of CouchApps we could run it on that can handle Markdown. Under ASF guidelines I'm pretty sure we don't need to worry about CLAs for documentation contributors. Let's get the barrier to entry for new documenters as low as possible. Chris
[jira] Assigned: (COUCHDB-645) _update: document created with undefined _id
[
https://issues.apache.org/jira/browse/COUCHDB-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson reassigned COUCHDB-645:
--
Assignee: Chris Anderson
_update: document created with undefined _id
Key: COUCHDB-645
URL: https://issues.apache.org/jira/browse/COUCHDB-645
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.11
Environment: Linux, CouchDB built from HEAD
Reporter: Cliff Stanford
Assignee: Chris Anderson
Attachments: updates_handler.patch
Using an update handler, if a document is returned with { _id : undefined
}, the document will be created on the database with an undefined _id and
will henceforth not be accessible to modify or delete although it will show
up in views.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-684) Futon security dialog overwrites other properties of security doc
[ https://issues.apache.org/jira/browse/COUCHDB-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842377#action_12842377 ] Brian Candler commented on COUCHDB-684: --- another option would be to add an _id field to the actual JSON response. certainly easier, especially for non-Futon clients, but I'm wary about faking the API so much. If you were to store a random _rev in the _security object itself, then you could implement concurrency control for _security without too much work AFAICS. It would only be half-baked, but since _security doesn't replicate it wouldn't matter. Then if you're going to store/update _rev, you might as well set _id:_security at the same time. That is, you wouldn't be faking up the API, so much as adding some fixed data into _security to make it look more like a doc. Futon security dialog overwrites other properties of security doc - Key: COUCHDB-684 URL: https://issues.apache.org/jira/browse/COUCHDB-684 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 0.11 Environment: OSX 10.6 Reporter: David Goodlad Attachments: futon_security.patch When the _security document has existing properties other than readers and admins, Futon's security dialog will overwrite them. If it's agreed this is undesirable behaviour, I'll see about putting a patch together. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: vhost + rewrite issues
On Sun, Mar 7, 2010 at 6:37 AM, Mikeal Rogers mikeal.rog...@gmail.com wrote: dgoodlad you can use '../' to refer to the path above the design doc, and so on Problem solved :) I updated the wiki. There are also some examples in the tests. - benoit
Re: CouchDB Wiki / Documentation
On Mar 7, 2010, at 3:11 AM, J Chris Anderson wrote: On Mar 6, 2010, at 4:47 PM, Noah Slater wrote: On 7 Mar 2010, at 00:38, Mikeal Rogers wrote: We can provide the same providence and copyright assurances outside of JIRA. It's a checkbox, it's not hard. I agree. I don't want to be misunderstood as fighting against the initiative of improving our documentation. I just want to make sure we do it in a way that embraces our parent organisation. And as far as I know, and I am incorrect rather frequently, that involves hosting whatever we use on ASF infrastructure, and taking the proper measures to make sure that what is produced is free for the community to use, where free is the ASF's definition of free. If we can satisfy that, and improve our documentation, it will have my full support. However, just creating a new repository on Github and linking to it from our site is not satisfactory. I think the short run, putting together an informal Markdown repository of docs or proto-docs would be cool. I don't care where it live but we'll need to get an ASF Zone for a project CouchDB instance. I guess this means Damien has to send an email to infra. It's simple to have CouchDB render Markdown. After 0.11 is out and we launch the project CouchDB instance, I'm sure there are a ton of CouchApps we could run it on that can handle Markdown. I really like the idea of this dogfood exercise. With respect to Markdown, I'd like to also mention Org for those who are emacs users. It can be used for everything from project management to publishing web pages, journal articles, you name it. One can even embed LaTex in it. For those who already know Org, markdown-mode[1] enables editing of markdown with org style cycling, etc.. it can be published to any format. I think the closer to doc stays to the code the more apt it is to be read, written, and useful. I'm wondering how useful it might be to have some of these markdown files reside with the code in the repository. [1] http://jblevins.org/projects/markdown-mode/ Under ASF guidelines I'm pretty sure we don't need to worry about CLAs for documentation contributors. Let's get the barrier to entry for new documenters as low as possible. Chris
[jira] Commented: (COUCHDB-679) Pull replication no longer works when a source doc has a large attachment
[
https://issues.apache.org/jira/browse/COUCHDB-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842468#action_12842468
]
Filipe Manana commented on COUCHDB-679:
---
@Jan,
have you tried the latest version of the test?
cheers
Pull replication no longer works when a source doc has a large attachment
-
Key: COUCHDB-679
URL: https://issues.apache.org/jira/browse/COUCHDB-679
Project: CouchDB
Issue Type: Bug
Components: Replication
Environment: trunk and 0.11
Reporter: Filipe Manana
Priority: Blocker
Fix For: 0.11
Attachments: CouchDB-679-etap_test-trunk-2.patch,
CouchDB-679-etap_test-trunk-3.patch, CouchDB-679-etap_test-trunk.patch
After rev r916868 (fix for CouchDB-597), doing a pull replication of a doc
that has a large attachment no longer works.
The problem is in couch_rep_att.erl:
convert_stub(#att{data=stub, name=Name} = Attachment,
{#http_db{} = Db, Id, Rev}) -
{Pos, [RevId|_]} = Rev,
Request = Db#http_db{
resource = lists:flatten([couch_util:url_encode(Id), /,
couch_util:url_encode(Name)]),
qs = [{rev, couch_doc:rev_to_str({Pos,RevId})}]
},
Ref = make_ref(),
RcvFun = fun() -
Bin = attachment_receiver(Ref, Request),
cleanup(),
Bin
end,
Attachment#att{data=RcvFun}.
The cleanup/0 function can not be called there, since when the attachment is
received in multiple chunks, after receiving the first chunk the subsequent
ones are silently discarded by cleanup/0:
cleanup() -
receive
{ibrowse_async_response, _, _} -
%% TODO maybe log, didn't expect to have data here
cleanup();
{ibrowse_async_response_end, _} -
cleanup();
{ibrowse_async_headers, _, _, _} -
cleanup()
after 0 -
erase(),
ok
end.
If you look into couch_db.erl, you'll see that the attachment receiver
function maybe called multiple times:
flush_att(Fd, #att{data=Fun,att_len=AttLen}=Att) when is_function(Fun) -
with_stream(Fd, Att, fun(OutputStream) -
write_streamed_attachment(OutputStream, Fun, AttLen)
end).
write_streamed_attachment(_Stream, _F, 0) -
ok;
write_streamed_attachment(Stream, F, LenLeft) -
Bin = F(),
ok = couch_stream:write(Stream, Bin),
write_streamed_attachment(Stream, F, LenLeft - size(Bin)).
This is serious :(
However, removing that call to cleanup/0 may cause the return of CouchDB-597,
therefore I don't supply a patch here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Storing OAuth tokens in the users database
On Fri, Nov 27, 2009 at 12:15 AM, Jan Lehnardt j...@apache.org wrote: Hi all, I created a branch* based on trunk that allows storing of OAuth tokens, users and secrets in the users database instead of the ini file / config system. The design is pretty simple: If you set the config var `use_users_db` to `true` in the `couch_httpd_oauth ` section of your ini file, CouchDB will look for all OAuth information inside the users database for each OAuth request that comes in. Internally, it creates a new design document with three views that are called for authenticating each request. Future versions could merge the three views to two or one, but I kept it simple for now. The branch comes with tests and all other tests still run fine. I haven't done any heavy duty performance analysis, but I hope Canonical can step in here (since they can put this to good use on UbuntuOne). There's also a special version of this branch** that is based on 0.10.x + Canonical specific patches. Since we won't put any new features in 0.10 and this clearly is a new feature, I only propose this branch to be merged into trunk / 0.11. The 0.10 version is still available on my Github repo for educational purposes (and Canonical of course). I hope you can give the branch a closer look and tell me if it looks like something we want to have merged into trunk. Thanks for your time! * http://github.com/janl/couchdb/tree/oauth-tokens-in-user-db Cheers Jan -- ** http://github.com/janl/couchdb/tree/ubuntuone Now that we have reader acl in couchdb, maybe we can do this. Would be useful when you want to store lot of token. I will test it on a recent couchdb today I hope there aren't too many changes. - benoît
