[jira] [Commented] (COUCHDB-1447) X-Couch-Update-NewRev header is missed if custom headers are specified in response of _update handler
[
https://issues.apache.org/jira/browse/COUCHDB-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280150#comment-14280150
]
Benjamin Young commented on COUCHDB-1447:
-
Just ran into this problem...
+1 to merging the X-Couch-Update-NewRev into any custom headers.
X-Couch-Update-NewRev header is missed if custom headers are specified in
response of _update handler
-
Key: COUCHDB-1447
URL: https://issues.apache.org/jira/browse/COUCHDB-1447
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface, View Server Support
Affects Versions: 1.2, 1.3
Environment: Apache CouchDB 1.3.0a-a2bea1f-git
Apache CouchDB 1.2.0a-94e72e7-git
Reporter: Alexander Shorin
Priority: Minor
{
_id: _design/dump,
_rev: 1-74b49af793bd5ce090712f638c3c920e,
updates: {
doc: function(doc, req){ return [doc, {headers: {'Content-Type':
'text/html'}, 'body': 'h1test/h1'}]}
}
}
curl -v -X PUT
http://localhost:5984/app%2fdefault/_design/dump/_update/doc/foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
PUT /app%2fdefault/_design/dump/_update/doc/foo HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
zlib/1.2.6
Host: localhost:5984
Accept: */*
HTTP/1.1 201 Created
Server: CouchDB/1.3.0a-a2bea1f-git (Erlang OTP/R15B)
Date: Mon, 19 Mar 2012 01:45:20 GMT
Content-Type: text/html
Content-Length: 13
* Connection #0 to host localhost left intact
h1test/h1* Closing connection #0
{
_id: _design/dump,
_rev: 2-f1c20db4fb28846399ab1cecaa9d2f28,
updates: {
doc: function(doc, req){ return [doc, {'body': 'h1test/h1'}]}
}
}
curl -v -X PUT
http://localhost:5984/app%2fdefault/_design/dump/_update/doc/foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
PUT /app%2fdefault/_design/dump/_update/doc/foo HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
zlib/1.2.6
Host: localhost:5984
Accept: */*
HTTP/1.1 201 Created
X-Couch-Update-NewRev: 4-89c1c79a98fc269e474eb64d999a2049
Server: CouchDB/1.3.0a-a2bea1f-git (Erlang OTP/R15B)
Date: Mon, 19 Mar 2012 01:46:43 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 13
* Connection #0 to host localhost left intact
h1test/h1* Closing connection #0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2052) Add API for discovering feature availability
[
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993880#comment-13993880
]
Benjamin Young commented on COUCHDB-2052:
-
Strangely (to me) I've only just found
[RFC2295|http://tools.ietf.org/html/rfc2295]. [Section
8|http://tools.ietf.org/html/rfc2295#section-8] introduces a set of HTTP
headers that would (have...) made feature and content-type discovery by agents
(in this case, CouchDB clients) much simpler.
Of the headers, {{Accept-Features}} and {{Alternates}} would be of particular
interest to this discussion.
Add API for discovering feature availability
Key: COUCHDB-2052
URL: https://issues.apache.org/jira/browse/COUCHDB-2052
Project: CouchDB
Issue Type: Improvement
Security Level: public(Regular issues)
Components: HTTP Interface
Reporter: Jens Alfke
I propose adding to the response of GET / a property called features or
extensions whose value is an array of strings, each string being an
agreed-upon identifier of a specific optional feature. For example:
{couchdb: welcome, features: [_bulk_get, persona]}, vendor:
…
Rationale:
Features are being added to CouchDB over time, plug-ins may add features, and
there are compatible servers that may have nonstandard features (like
_bulk_get). But there isn't a clear way for a client (which might be another
server's replicator) to determine what features a server has. Currently a
client looking at the response of a GET / has to figure out what server and
version thereof it's talking to, and then has to consult hardcoded knowledge
that version X of server Y supports feature Z.
(True, you can often get away without needing to check, by assuming a feature
exists but falling back to standard behavior if you get an error. But not all
features may be so easy to detect — the behavior of an unaware server might
be to ignore the feature and do the wrong thing, rather than returning an
error — and anyway this adds extra round-trips that slow down the operation.)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (COUCHDB-1870) New View: Add language option
[ https://issues.apache.org/jira/browse/COUCHDB-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young reassigned COUCHDB-1870: --- Assignee: Garren Smith (was: Benjamin Young) Refactoring this is beyond me, atm, so I'm tossing it back your way--just so it doesn't sit in limbo. If I see a clear way forward for it, I shall return! ;) Thanks. New View: Add language option - Key: COUCHDB-1870 URL: https://issues.apache.org/jira/browse/COUCHDB-1870 Project: CouchDB Issue Type: Task Components: Fauxton Reporter: Sue Lockwood Assignee: Garren Smith Labels: advanced Add the language option to the new view section http://dl.dropboxusercontent.com/u/44146427/Screenshots/64.png -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (COUCHDB-2185) Database redirects
Benjamin Young created COUCHDB-2185: --- Summary: Database redirects Key: COUCHDB-2185 URL: https://issues.apache.org/jira/browse/COUCHDB-2185 Project: CouchDB Issue Type: Story Security Level: public (Regular issues) Reporter: Benjamin Young This is totally a random idea, but one that would further [Webize |http://www.w3.org/DesignIssues/Webize.html] CouchDB. As a developer, I need a way to “tombstone” old database names and redirect traffic to the new location. The Web has this in the form of 301/302 redirects. Perhaps we could have a config section or some other way to mark a DB file as serving as a redirect to another one. I realize this is likely one of the larger “can of worm” ideas posted in the life of any open source project. So take all of it with several grains of salt. ^_^ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COUCHDB-2185) Database redirects
[ https://issues.apache.org/jira/browse/COUCHDB-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young resolved COUCHDB-2185. - Resolution: Duplicate [~dch]...always way out in front. :) Thanks [~kxepal]! Database redirects -- Key: COUCHDB-2185 URL: https://issues.apache.org/jira/browse/COUCHDB-2185 Project: CouchDB Issue Type: Story Security Level: public(Regular issues) Reporter: Benjamin Young This is totally a random idea, but one that would further [Webize |http://www.w3.org/DesignIssues/Webize.html] CouchDB. As a developer, I need a way to “tombstone” old database names and redirect traffic to the new location. The Web has this in the form of 301/302 redirects. Perhaps we could have a config section or some other way to mark a DB file as serving as a redirect to another one. I realize this is likely one of the larger “can of worm” ideas posted in the life of any open source project. So take all of it with several grains of salt. ^_^ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-1736) Database aliases
[
https://issues.apache.org/jira/browse/COUCHDB-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919820#comment-13919820
]
Benjamin Young commented on COUCHDB-1736:
-
Consider my duplicate ticket filing a +1 for this idea. :-P
[~kocolosk]'s approach sounds spot on, and it seems it'd be a good time (just
after the first BigCouch-based release) to add this as a feature.
+1 for recommending [~kxepal]'s {{_config}} level redirect option in the
meantime.
Database aliases
Key: COUCHDB-1736
URL: https://issues.apache.org/jira/browse/COUCHDB-1736
Project: CouchDB
Issue Type: Improvement
Reporter: Dave Cottlehuber
Labels: gsoc, mentor
Support redirecting database names at HTTP layer. e.g. GET /foo is passed to
/bar database internally.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (COUCHDB-2181) Show function with provides() fails to handle `json` key
Benjamin Young created COUCHDB-2181:
---
Summary: Show function with provides() fails to handle `json` key
Key: COUCHDB-2181
URL: https://issues.apache.org/jira/browse/COUCHDB-2181
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: JavaScript View Server
Reporter: Benjamin Young
The documentation for [Show
functions|http://docs.couchdb.org/en/latest/couchapp/ddocs.html#show-functions]
has the following code:
{code:javascript}
function(doc, req){
provides('json', function(){
return {'json': doc}
});
}
{code}
However, using that returns an empty body—though it does properly set
Content-Type, etc.
The cause is that the ‘json’ key is not checked/processed by the Mime and/or
Render code, but should be if the response type is JSON (at least).
Short term fix: update the docs to use the {{\{body: JSON.stringify(doc)\}}}
return value instead.
Long(er) term / more-correct fix: fix the Mime/Render code to address…and then
put the docs back the way they are currently (if we did the short term fix).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (COUCHDB-2086) Modal backdrop broken in Chrome
[ https://issues.apache.org/jira/browse/COUCHDB-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young resolved COUCHDB-2086. - Resolution: Fixed Seems only right that my first commit as a committer is to fix a bug I introduced. :-P Thanks for the patience, all. :) Modal backdrop broken in Chrome --- Key: COUCHDB-2086 URL: https://issues.apache.org/jira/browse/COUCHDB-2086 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Fauxton Reporter: Benjamin Young Assignee: Benjamin Young I broke this inadvertently when fixing the “one-pane” shifting over the navigation problem: https://github.com/apache/couchdb/commit/e389a8ba2a79da2669b536ca242b5dfdee4faba3 It’s caused by Webkit’s way of fixed positioned elements changing the stacking context: http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements There’s a few ways to fixe it. Here’s one: http://stackoverflow.com/questions/19917026/bootstrap-modal-z-index Will be working on this tomorrow (14 hours from now), but reporting it to let everyone know that it’s a) broken and that b) a patch is forthcoming. Sorry for the bug. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2071) Improve new database UI
[ https://issues.apache.org/jira/browse/COUCHDB-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young reassigned COUCHDB-2071: --- Assignee: Benjamin Young Improve new database UI --- Key: COUCHDB-2071 URL: https://issues.apache.org/jira/browse/COUCHDB-2071 Project: CouchDB Issue Type: Task Security Level: public(Regular issues) Components: Fauxton Reporter: Simon Metson Assignee: Benjamin Young The new database button uses a browser dialog. This prevents giving warning/documentation about invalid database names and makes creating a database after a failed attempt more difficult than it needs to be. (Reported by Alexander Shorin) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2086) Modal backdrop broken in Chrome
[ https://issues.apache.org/jira/browse/COUCHDB-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910795#comment-13910795 ] Benjamin Young commented on COUCHDB-2086: - Thanks, [~drsm79]! However, I think a full revert of the breaking commit is cleaner (hope that’s OK!): https://github.com/apache/couchdb/pull/156 That should clean house and remove the other change to that section that only had value if position: fixed stayed set. Modal backdrop broken in Chrome --- Key: COUCHDB-2086 URL: https://issues.apache.org/jira/browse/COUCHDB-2086 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Fauxton Reporter: Benjamin Young Assignee: Benjamin Young I broke this inadvertently when fixing the “one-pane” shifting over the navigation problem: https://github.com/apache/couchdb/commit/e389a8ba2a79da2669b536ca242b5dfdee4faba3 It’s caused by Webkit’s way of fixed positioned elements changing the stacking context: http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements There’s a few ways to fixe it. Here’s one: http://stackoverflow.com/questions/19917026/bootstrap-modal-z-index Will be working on this tomorrow (14 hours from now), but reporting it to let everyone know that it’s a) broken and that b) a patch is forthcoming. Sorry for the bug. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1606) Replicator leaves plaintext password in logs
[ https://issues.apache.org/jira/browse/COUCHDB-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910850#comment-13910850 ] Benjamin Young commented on COUCHDB-1606: - [~kocolosk] I hit this just now… Given the caveats, what’s your recommendation? Would love to see this put to rest to help boost confidence in CouchDB. Thanks! Replicator leaves plaintext password in logs Key: COUCHDB-1606 URL: https://issues.apache.org/jira/browse/COUCHDB-1606 Project: CouchDB Issue Type: Bug Components: Logging, Replication Affects Versions: 1.2 Reporter: Nathan Vander Wilt Assignee: Bob Dionne Attachments: pwd log.txt While reviewing logs, I noticed that a password had been recorded in the logs as part of a replicator error. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2086) Modal backdrop broken in Chrome
[ https://issues.apache.org/jira/browse/COUCHDB-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young reassigned COUCHDB-2086: --- Assignee: Benjamin Young Modal backdrop broken in Chrome --- Key: COUCHDB-2086 URL: https://issues.apache.org/jira/browse/COUCHDB-2086 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Fauxton Reporter: Benjamin Young Assignee: Benjamin Young I broke this inadvertently when fixing the “one-pane” shifting over the navigation problem: https://github.com/apache/couchdb/commit/e389a8ba2a79da2669b536ca242b5dfdee4faba3 It’s caused by Webkit’s way of fixed positioned elements changing the stacking context: http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements There’s a few ways to fixe it. Here’s one: http://stackoverflow.com/questions/19917026/bootstrap-modal-z-index Will be working on this tomorrow (14 hours from now), but reporting it to let everyone know that it’s a) broken and that b) a patch is forthcoming. Sorry for the bug. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (COUCHDB-2029) Consolidate CSS/LESS class name usage to minimize custom-ness
[ https://issues.apache.org/jira/browse/COUCHDB-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young resolved COUCHDB-2029. - Resolution: Fixed Fix Version/s: 1.6.0 This is really ongoing work, but the first (heavy) pass of it is complete and merged in these commits: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=6ea2b081bccb77acd04b59dc392be74c26714f82 and more recently: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=5d17c204dbcefc389420fef79810a58be91cde71 Consolidate CSS/LESS class name usage to minimize custom-ness - Key: COUCHDB-2029 URL: https://issues.apache.org/jira/browse/COUCHDB-2029 Project: CouchDB Issue Type: Improvement Components: Fauxton Reporter: Benjamin Young Assignee: Benjamin Young Fix For: 1.6.0 Right now Fauxton has loads of non-Bootstrap class names and styles for things that Bootstrap has a name for (ex: .button vs. .btn). Often those class names and styles compete and sometimes are even used together causing a pretty tangled mess. Focusing our use of class names on the Bootstrap defined ones gives new comers to the code documentation on what classes mean what--and we don't even have to maintain it! :D If you know Bootstrap, you should be able to know how to add buttons, etc to Fauxton without getting tripped up by .button .red .outlineGray, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2086) Modal backdrop broken in Chrome
Benjamin Young created COUCHDB-2086: --- Summary: Modal backdrop broken in Chrome Key: COUCHDB-2086 URL: https://issues.apache.org/jira/browse/COUCHDB-2086 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Fauxton Reporter: Benjamin Young I broke this inadvertently when fixing the “one-pane” shifting over the navigation problem: https://github.com/apache/couchdb/commit/e389a8ba2a79da2669b536ca242b5dfdee4faba3 It’s caused by Webkit’s way of fixed positioned elements changing the stacking context: http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements There’s a few ways to fixe it. Here’s one: http://stackoverflow.com/questions/19917026/bootstrap-modal-z-index Will be working on this tomorrow (14 hours from now), but reporting it to let everyone know that it’s a) broken and that b) a patch is forthcoming. Sorry for the bug. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2014) Fauxton requires full admin rights to access secondary indexes
[ https://issues.apache.org/jira/browse/COUCHDB-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young reassigned COUCHDB-2014: --- Assignee: Benjamin Young Fauxton requires full admin rights to access secondary indexes -- Key: COUCHDB-2014 URL: https://issues.apache.org/jira/browse/COUCHDB-2014 Project: CouchDB Issue Type: Bug Components: Fauxton Reporter: Hans J Schroeder Assignee: Benjamin Young Fauxton requires full admin rights to access secondary indexes where db admin right should be enough. Step to reproduce: In futon everything works as expected: 1. As admin create a database aaa 2. Set security to admin: [usera] and member: [usera] 3. Create a view all/by_id 4. Log in as usera and open the view all/by_id In fauxton: 1. Login as usera 2. Open the database aaa 3. Click on the secondary index all/by_id - This leads to no access and opens the login page. I guess it has something to do with routeroles being to strict. The no access is generated client-side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2062) Write documentation on how to create an addon
[ https://issues.apache.org/jira/browse/COUCHDB-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young reassigned COUCHDB-2062: --- Assignee: Benjamin Young Write documentation on how to create an addon - Key: COUCHDB-2062 URL: https://issues.apache.org/jira/browse/COUCHDB-2062 Project: CouchDB Issue Type: New Feature Security Level: public(Regular issues) Components: Documentation, Fauxton Reporter: Garren Smith Assignee: Benjamin Young Currently we have a very basic introduction to addons and how Fauxton. We need better documentation on how Fauxton works and how to create an addon, add styling etc. We can use https://github.com/apache/couchdb/blob/master/src/fauxton/writing_addons.md and the https://github.com/apache/couchdb/blob/master/src/fauxton/readme.md as starting points. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2052) Add API for discovering feature availability
[
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894623#comment-13894623
]
Benjamin Young commented on COUCHDB-2052:
-
[~klaus_trainer] great thread! Good thoughts in there that do match this
conversation closely.
[~snej] you're absolutely correct that just exposing URL endpoint existence is
not enough. Document types, capability's (thanks, Klaus!), etc. have to be
identifiable and understandable (or ignored).
jsonapi.com came up in the thread Klaus linked too, and it's very much like the
other JSON-based Hypermedia API options mentioned above--it's a small group of
inventors and all these folks cross paths often. :)
One thing that a good Hypermedia API provides is affordances:
bq. ...the term affordance refers to the perceived and actual properties of the
thing, primarily those fundamental properties that determine just how the thing
could possibly be used. (pg 9)
??The (Design|Psychology) of Everyday Things (Norman, 1988)??
Cribbed that quote from [this great blog
post|http://www.amundsen.com/blog/archives/1109] on the topic by Mike Amundsen
who also wrote [Hypermedia-Oriented
Design|http://www.w3.org/2011/10/integration-workshop/p/hypermedia-oriented-design.pdf].
Affordances is a broad concept that encompasses more than just URL exposure. It
can (and should) include defining document types (as the above Hypermedia API
options have done...and registered them with IANA, so others can find them).
[~snej] in the case of the channels document additions, those documents would
have their magic defined in a media (formerly MIME) type named something like
{{application/vnd.couchbase.channel+json}}. The endpoints that traffic in those
documents could then handle either respond/accept raw JSON
({{application/json}}) or ({{application/vnd.couchbase.channel+json}}). Both
are just JSON, but in the later format some features are assumed, required,
expected.
JSON Schema's (or similar) could be provided and referenced (where
appropriate/expected depending on the format...and of course with human-focused
documentation), so validating, editing, and processing these JSON-based media
types would be a known quantity and not anybody's guess what channel or
_rev for that matter might mean, do, etc.
In the end, it's quite similar to the CAPAB option mentioned in the thread
Klaus linked to. Just with the addition of URL's for all those CAPAB's, so they
can be dereferenced, understood, and used more easily and more globally.
That's the idea anyway. :)
Add API for discovering feature availability
Key: COUCHDB-2052
URL: https://issues.apache.org/jira/browse/COUCHDB-2052
Project: CouchDB
Issue Type: Improvement
Security Level: public(Regular issues)
Components: HTTP Interface
Reporter: Jens Alfke
I propose adding to the response of GET / a property called features or
extensions whose value is an array of strings, each string being an
agreed-upon identifier of a specific optional feature. For example:
{couchdb: welcome, features: [_bulk_get, persona]}, vendor:
…
Rationale:
Features are being added to CouchDB over time, plug-ins may add features, and
there are compatible servers that may have nonstandard features (like
_bulk_get). But there isn't a clear way for a client (which might be another
server's replicator) to determine what features a server has. Currently a
client looking at the response of a GET / has to figure out what server and
version thereof it's talking to, and then has to consult hardcoded knowledge
that version X of server Y supports feature Z.
(True, you can often get away without needing to check, by assuming a feature
exists but falling back to standard behavior if you get an error. But not all
features may be so easy to detect — the behavior of an unaware server might
be to ignore the feature and do the wrong thing, rather than returning an
error — and anyway this adds extra round-trips that slow down the operation.)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2052) Add API for discovering feature availability
[
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894639#comment-13894639
]
Benjamin Young commented on COUCHDB-2052:
-
[~benoitc] by using URI (and not URL) in your comment above, you prove the
point. :) URI's are just identifiers. They can be relative, absolute, and even
non-dereferencable (if you want to go there...).
To your point about protocols. It can be a tangled word. CouchDB (et al) use
HTTP for their protocol. Anything we do inside or on top of that could be
considered a protocol as well, but that starts to tangle things up a bit.
We'll be best served if we cut with the grain of the web and use the pieces
as they were designed: URI's, HTTP methods, media types, etc.
Feature and capability aren't new territory. We'd be best served by rinsing
and repeating some proven method of scalable resource discover-ability...like
the Web. :)
Add API for discovering feature availability
Key: COUCHDB-2052
URL: https://issues.apache.org/jira/browse/COUCHDB-2052
Project: CouchDB
Issue Type: Improvement
Security Level: public(Regular issues)
Components: HTTP Interface
Reporter: Jens Alfke
I propose adding to the response of GET / a property called features or
extensions whose value is an array of strings, each string being an
agreed-upon identifier of a specific optional feature. For example:
{couchdb: welcome, features: [_bulk_get, persona]}, vendor:
…
Rationale:
Features are being added to CouchDB over time, plug-ins may add features, and
there are compatible servers that may have nonstandard features (like
_bulk_get). But there isn't a clear way for a client (which might be another
server's replicator) to determine what features a server has. Currently a
client looking at the response of a GET / has to figure out what server and
version thereof it's talking to, and then has to consult hardcoded knowledge
that version X of server Y supports feature Z.
(True, you can often get away without needing to check, by assuming a feature
exists but falling back to standard behavior if you get an error. But not all
features may be so easy to detect — the behavior of an unaware server might
be to ignore the feature and do the wrong thing, rather than returning an
error — and anyway this adds extra round-trips that slow down the operation.)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2052) Add API for discovering feature availability
[
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893457#comment-13893457
]
Benjamin Young commented on COUCHDB-2052:
-
There's a lot of work being done in the Hypermedia API world around just this
issue. The response can carry that information in a less-meta way by using good
ole hyperlinks. :)
There are several options here (and it's a growing list):
* Hypermedia Application Layer (HAL) -
http://stateless.co/hal_specification.html
* Hydra - http://www.markus-lanthaler.com/hydra/
* Collection+JSON - http://amundsen.com/media-types/collection/
More general info: http://amundsen.com/hypermedia/
Using Hypermedia is far more resilient than using magic strings that a human
has to look up and hard code meaning for into their client-code...which is what
we do now. Using a known Hypermedia format (there are loads more than those 3
JSON-focused ones), provide a shared foundation and community that can grow
collectively, CouchDB (and friends) can all participate, and we get a wider set
of tools, developers, conferences, etc interested in our API...or that's the
idea. ;)
Thanks for bringing this up in any case, Jens!
Add API for discovering feature availability
Key: COUCHDB-2052
URL: https://issues.apache.org/jira/browse/COUCHDB-2052
Project: CouchDB
Issue Type: Improvement
Security Level: public(Regular issues)
Components: HTTP Interface
Reporter: Jens Alfke
I propose adding to the response of GET / a property called features or
extensions whose value is an array of strings, each string being an
agreed-upon identifier of a specific optional feature. For example:
{couchdb: welcome, features: [_bulk_get, persona]}, vendor:
…
Rationale:
Features are being added to CouchDB over time, plug-ins may add features, and
there are compatible servers that may have nonstandard features (like
_bulk_get). But there isn't a clear way for a client (which might be another
server's replicator) to determine what features a server has. Currently a
client looking at the response of a GET / has to figure out what server and
version thereof it's talking to, and then has to consult hardcoded knowledge
that version X of server Y supports feature Z.
(True, you can often get away without needing to check, by assuming a feature
exists but falling back to standard behavior if you get an error. But not all
features may be so easy to detect — the behavior of an unaware server might
be to ignore the feature and do the wrong thing, rather than returning an
error — and anyway this adds extra round-trips that slow down the operation.)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-1870) New View: Add language option
[ https://issues.apache.org/jira/browse/COUCHDB-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878770#comment-13878770 ] Benjamin Young commented on COUCHDB-1870: - On going conversation happening on the 137 Pull Request: https://github.com/apache/couchdb/pull/137 Basically, this needs to be more modular than it is now so we can support more languages and untangle config from the Documents section so Fauxton can be more broadly usable. New View: Add language option - Key: COUCHDB-1870 URL: https://issues.apache.org/jira/browse/COUCHDB-1870 Project: CouchDB Issue Type: Task Components: Fauxton Reporter: Sue Lockwood Assignee: Benjamin Young Add the language option to the new view section http://dl.dropboxusercontent.com/u/44146427/Screenshots/64.png -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1870) New View: Add language option
[ https://issues.apache.org/jira/browse/COUCHDB-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877897#comment-13877897 ] Benjamin Young commented on COUCHDB-1870: - PR sent: https://github.com/apache/couchdb/pull/137 New View: Add language option - Key: COUCHDB-1870 URL: https://issues.apache.org/jira/browse/COUCHDB-1870 Project: CouchDB Issue Type: Task Components: Fauxton Reporter: Sue Lockwood Assignee: Benjamin Young Add the language option to the new view section http://dl.dropboxusercontent.com/u/44146427/Screenshots/64.png -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COUCHDB-1710) Update NOTICE file with various license info from fauxton dependencies
[ https://issues.apache.org/jira/browse/COUCHDB-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-1710: Summary: Update NOTICE file with various license info from fauxton dependencies (was: Update LICENSE file with various license info from fauxton dependencies) Update NOTICE file with various license info from fauxton dependencies -- Key: COUCHDB-1710 URL: https://issues.apache.org/jira/browse/COUCHDB-1710 Project: CouchDB Issue Type: Bug Components: Fauxton Reporter: Russell Branca Assignee: Russell Branca This wasn't done on the initial fauxton merge, I'll get it taken care of. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1827) Add Fauxton ui components
[ https://issues.apache.org/jira/browse/COUCHDB-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873570#comment-13873570 ] Benjamin Young commented on COUCHDB-1827: - Happy to hack on this one! If you can point me to a few things you know need component-izing, that'd be super helpful. Otherwise, I'll get a branch going and see what I can do. Add Fauxton ui components - Key: COUCHDB-1827 URL: https://issues.apache.org/jira/browse/COUCHDB-1827 Project: CouchDB Issue Type: New Feature Components: Fauxton Reporter: Garren Smith Fauxton has a fair amount of code repetition with modals, tab editors etc. The aim is to build some common UI components that can be used in all the modules. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1710) Update NOTICE file with various license info from fauxton dependencies
[ https://issues.apache.org/jira/browse/COUCHDB-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873564#comment-13873564 ] Benjamin Young commented on COUCHDB-1710: - This looks complete--unless there are (and this is likely) some newer things that needed adding. Lots of JS in there regardless. :) Update NOTICE file with various license info from fauxton dependencies -- Key: COUCHDB-1710 URL: https://issues.apache.org/jira/browse/COUCHDB-1710 Project: CouchDB Issue Type: Bug Components: Fauxton Reporter: Russell Branca Assignee: Russell Branca This wasn't done on the initial fauxton merge, I'll get it taken care of. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-259) Ability to store abitrary data in attachment stubs
[
https://issues.apache.org/jira/browse/COUCHDB-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873711#comment-13873711
]
Benjamin Young commented on COUCHDB-259:
Some work on this was done in a couple Github PRs:
https://github.com/apache/couchdb/pull/54
https://github.com/apache/couchdb/pull/51
Ability to store abitrary data in attachment stubs
--
Key: COUCHDB-259
URL: https://issues.apache.org/jira/browse/COUCHDB-259
Project: CouchDB
Issue Type: Wish
Components: Database Core
Affects Versions: 0.8.1
Reporter: Sho Fukamachi
Assignee: Dave Cottlehuber
Priority: Minor
I suggest the ability to store arbitrary data in line with single attachments
to a doc. The mooted use is to store metadata about that attachment.
For example, a current attachment:
m['_attachments']
= {yamanote.jpg={content_type=image/jpeg, stub=true,
length=382613}}
Desired behaviour is to be able to insert persistent metadata like so:
m['_attachments']
= {yamanote.jpg={content_type=image/jpeg, stub=true,
length=382613, width = 800, height = 600, md5 =
95de7a118ee28824afa8d2ad8fe5819f}}
And many other use cases according to media type.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-1827) Add Fauxton ui components
[ https://issues.apache.org/jira/browse/COUCHDB-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873717#comment-13873717 ] Benjamin Young commented on COUCHDB-1827: - Thanks, Sue! I'll dig. Add Fauxton ui components - Key: COUCHDB-1827 URL: https://issues.apache.org/jira/browse/COUCHDB-1827 Project: CouchDB Issue Type: New Feature Components: Fauxton Reporter: Garren Smith Fauxton has a fair amount of code repetition with modals, tab editors etc. The aim is to build some common UI components that can be used in all the modules. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2029) Consolidate CSS/LESS class name usage to minimize custom-ness
[ https://issues.apache.org/jira/browse/COUCHDB-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young reassigned COUCHDB-2029: --- Assignee: Benjamin Young (was: Garren Smith) Consolidate CSS/LESS class name usage to minimize custom-ness - Key: COUCHDB-2029 URL: https://issues.apache.org/jira/browse/COUCHDB-2029 Project: CouchDB Issue Type: Improvement Components: Fauxton Reporter: Benjamin Young Assignee: Benjamin Young Right now Fauxton has loads of non-Bootstrap class names and styles for things that Bootstrap has a name for (ex: .button vs. .btn). Often those class names and styles compete and sometimes are even used together causing a pretty tangled mess. Focusing our use of class names on the Bootstrap defined ones gives new comers to the code documentation on what classes mean what--and we don't even have to maintain it! :D If you know Bootstrap, you should be able to know how to add buttons, etc to Fauxton without getting tripped up by .button .red .outlineGray, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2029) Consolidate CSS/LESS class name usage to minimize custom-ness
Benjamin Young created COUCHDB-2029: --- Summary: Consolidate CSS/LESS class name usage to minimize custom-ness Key: COUCHDB-2029 URL: https://issues.apache.org/jira/browse/COUCHDB-2029 Project: CouchDB Issue Type: Improvement Components: Fauxton Reporter: Benjamin Young Right now Fauxton has loads of non-Bootstrap class names and styles for things that Bootstrap has a name for (ex: .button vs. .btn). Often those class names and styles compete and sometimes are even used together causing a pretty tangled mess. Focusing our use of class names on the Bootstrap defined ones gives new comers to the code documentation on what classes mean what--and we don't even have to maintain it! :D If you know Bootstrap, you should be able to know how to add buttons, etc to Fauxton without getting tripped up by .button .red .outlineGray, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2029) Consolidate CSS/LESS class name usage to minimize custom-ness
[ https://issues.apache.org/jira/browse/COUCHDB-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870734#comment-13870734 ] Benjamin Young commented on COUCHDB-2029: - This is already in progress on this branch on Github: https://github.com/bigbluehat/couchdb/tree/style-tests-and-class-cleanups I'm working to keep it up to date with the latest from Fauxton. I'll ping for review once it's ready (or at least at the next merge-able point...as it'll be an ongoing effort). Thanks! Consolidate CSS/LESS class name usage to minimize custom-ness - Key: COUCHDB-2029 URL: https://issues.apache.org/jira/browse/COUCHDB-2029 Project: CouchDB Issue Type: Improvement Components: Fauxton Reporter: Benjamin Young Right now Fauxton has loads of non-Bootstrap class names and styles for things that Bootstrap has a name for (ex: .button vs. .btn). Often those class names and styles compete and sometimes are even used together causing a pretty tangled mess. Focusing our use of class names on the Bootstrap defined ones gives new comers to the code documentation on what classes mean what--and we don't even have to maintain it! :D If you know Bootstrap, you should be able to know how to add buttons, etc to Fauxton without getting tripped up by .button .red .outlineGray, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1960) Provide pagination for /_all_dbs
[
https://issues.apache.org/jira/browse/COUCHDB-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13851860#comment-13851860
]
Benjamin Young commented on COUCHDB-1960:
-
[~chewbranca] knows the code coming in the future from the BigCouch
merge--which would obviate the need for this code. Obviously, that's a ways
out...but if the APIs and functionality are equivalent, then I think it'd be
good to have the API ship sooner than later--barring any Erlang-level issues
(to which I am currently unqualified to speak). :) Thanks, all.
Provide pagination for /_all_dbs
Key: COUCHDB-1960
URL: https://issues.apache.org/jira/browse/COUCHDB-1960
Project: CouchDB
Issue Type: Improvement
Components: Fauxton, HTTP Interface
Reporter: Benjamin Young
The database-per-user design pattern has increased in popularity and
consequently causes long lists of databases when one hits {{/_all_dbs}}
To keep this sane, we need some pagination.
{{?skip=10limit=10}} style seems to be the simplest to implement (and there
should be existing code from Cloudant for this one).
Thanks!
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (COUCHDB-1960) Provide pagination for /_all_dbs
Benjamin Young created COUCHDB-1960:
---
Summary: Provide pagination for /_all_dbs
Key: COUCHDB-1960
URL: https://issues.apache.org/jira/browse/COUCHDB-1960
Project: CouchDB
Issue Type: Improvement
Components: Fauxton, HTTP Interface
Reporter: Benjamin Young
The database-per-user design pattern has increased in popularity and
consequently causes long lists of databases when one hits {{/_all_dbs}}
To keep this sane, we need some pagination.
{{?skip=10limit=10}} style seems to be the simplest to implement (and there
should be existing code from Cloudant for this one).
Thanks!
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (COUCHDB-1958) /_utils/fauxton opens all databases on dashboard
[
https://issues.apache.org/jira/browse/COUCHDB-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13846348#comment-13846348
]
Benjamin Young commented on COUCHDB-1958:
-
COUCHDB-1960 has the goods on the {{/_all_dbs?skip=10limit=10}} approach.
Fauxton can get along with out it for now, and use it later once it lands.
/_utils/fauxton opens all databases on dashboard
Key: COUCHDB-1958
URL: https://issues.apache.org/jira/browse/COUCHDB-1958
Project: CouchDB
Issue Type: Bug
Components: Fauxton
Reporter: Gregor Martynus
I'm using Hoodie and have an app with 100k+ databases. After opening Fauxton
it freezes and kills any browser, as it tries to get information about every
single one of them with separate requests.
Could we optionally turn the initial loading of databases off entirely? In a
database-per-user setup, it's not helpful anyway
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (COUCHDB-348) / should redirect to a human readable page when accessed from a browser
[
https://issues.apache.org/jira/browse/COUCHDB-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845452#comment-13845452
]
Benjamin Young commented on COUCHDB-348:
So clients can be changed far more easily than browser. Additionally, we can do
some User-Agent string sniffing if it comes to that.
curl sends {{Accept: */*}} and {{User-Agent: curl/7.30.0}} fwiw.
Browser sniffing is an old (dark) art, and seems it wouldn't be terrible to
tackle that and default to the {{application/json}} when we can't figure it out.
Certainly a note about the change with a minor (or major) point release along
with contacting client authors directly and even doing a bit of
testing/documenting/pull-requesting would be needed for the smoothest
transition.
It beats not doing it.
/ should redirect to a human readable page when accessed from a browser
---
Key: COUCHDB-348
URL: https://issues.apache.org/jira/browse/COUCHDB-348
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Reporter: Chris Anderson
Assignee: Robert Newson
Attachments: COUCHDB_348_01.patch, COUCHDB_348_02.patch,
COUCHDB_348_03.patch, encs.erl
As more people are adopting CouchDB, the number of questions along the lines
of All I see is {couchdb:Welcome,version:0.10.0a773399}, what now?
If this page redirected to /_utils/ (or maybe something more user-focussed)
when the accept headers included html, we could make the first-time user
experience more palatable.
There's some code in COUCHDB-234 that might be helpful here.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (COUCHDB-348) / should redirect to a human readable page when accessed from a browser
[
https://issues.apache.org/jira/browse/COUCHDB-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845470#comment-13845470
]
Benjamin Young commented on COUCHDB-348:
Meh. Plugin time.
/ should redirect to a human readable page when accessed from a browser
---
Key: COUCHDB-348
URL: https://issues.apache.org/jira/browse/COUCHDB-348
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Reporter: Chris Anderson
Assignee: Robert Newson
Attachments: COUCHDB_348_01.patch, COUCHDB_348_02.patch,
COUCHDB_348_03.patch, encs.erl
As more people are adopting CouchDB, the number of questions along the lines
of All I see is {couchdb:Welcome,version:0.10.0a773399}, what now?
If this page redirected to /_utils/ (or maybe something more user-focussed)
when the accept headers included html, we could make the first-time user
experience more palatable.
There's some code in COUCHDB-234 that might be helpful here.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (COUCHDB-348) / should redirect to a human readable page when accessed from a browser
[
https://issues.apache.org/jira/browse/COUCHDB-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845657#comment-13845657
]
Benjamin Young commented on COUCHDB-348:
Yeah, let's avoid the prefix conversation. If it must be done, it should happen
and be discussed elsewhere...so we don't derail this antique bug getting fixed.
;)
[~janl], I very much like the approach you've described. I do think it's
feasible to at least detect the big 3 browsers (Firefox, WebKit collective, and
IE) and route them accordingly--untold numbers of web servers do this
successfully...certainly we can find a way.
Another orthogonal discussion would be the use of something like HAL
(Hypermedia Application Language) for defining things like this link in the
JSON we return...but that's a separate can of worms that should stay separate.
;)
+1 on adding a link under vendor for now, and routing {{/}} to {{/_utils}} (or
wherever based on a config setting...ideally) following that.
Thanks, [~janl]
/ should redirect to a human readable page when accessed from a browser
---
Key: COUCHDB-348
URL: https://issues.apache.org/jira/browse/COUCHDB-348
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Reporter: Chris Anderson
Assignee: Robert Newson
Attachments: COUCHDB_348_01.patch, COUCHDB_348_02.patch,
COUCHDB_348_03.patch, encs.erl
As more people are adopting CouchDB, the number of questions along the lines
of All I see is {couchdb:Welcome,version:0.10.0a773399}, what now?
If this page redirected to /_utils/ (or maybe something more user-focussed)
when the accept headers included html, we could make the first-time user
experience more palatable.
There's some code in COUCHDB-234 that might be helpful here.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
[
https://issues.apache.org/jira/browse/COUCHDB-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843130#comment-13843130
]
Benjamin Young commented on COUCHDB-1303:
-
It would seem that allowing `_update` to store multiple documents would be the
easier approach.
This is the current code for saving documents and responding to an `_update`
request:
https://github.com/apache/couchdb/blob/master/src/couch_mrview/src/couch_mrview_show.erl#L131
Perhaps making the first element of the return array support multiple JSON
objects (i.e. return [[doc1, doc2], {..headers..}]; ) would be a good first
step.
The next step would be to allow `_update` (with no doc_id specified in the URL
support the bulk_docs JSON format for POSTs).
Likely this could be broken into two separate commits (and Jira tickets) as
they have separate value:
1. sending in a single `_update` request and having multiple documents changed
2. sending in a bulk_docs formatted `_update` POST and having those documents
handled and/or other documents generated/updated.
I don't think (now) that a `_bulk_update` endpoint would be needed.
Additionally, the use of redirect responses from an `_update` handler might
work now has a work around, it's not something I'd care to depend on (nor see
shipped in CouchDB) due to there being no guarantee that the Location header
would actually be followed by the client, and therefore no guarantee that the
second (or more) updates would actually be done. It could certainly work if you
control the whole stack and are OK with the potential of the redirects failing
at times.
Thanks for drawing attention to this issue in any case!
Add a _bulk_update handler similar to _update but for bulk document changes
---
Key: COUCHDB-1303
URL: https://issues.apache.org/jira/browse/COUCHDB-1303
Project: CouchDB
Issue Type: New Feature
Reporter: Benjamin Young
Labels: api, update_request_handler
_update handlers are great (and getting better!) for building RESTful API's
inside CouchDB. One limitation I found tonight is that _update can only do a
single document at a time. If the API I'm building needs to update multiple
docs (in a similar fashion to _bulk_docs), then an outside proxy script is
required. It would be ideal to have a _bulk_update handler to allow for the
same functionality as _update, but with the ability to insert multiple
documents at once.
Perhaps the current _update handler API could be extended to support multiple
IDs/documents, but a separate API endpoint would be seem reasonable if needed.
Thanks for considering this idea.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
[ https://issues.apache.org/jira/browse/COUCHDB-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843222#comment-13843222 ] Benjamin Young commented on COUCHDB-1303: - Good points. :) Given that, we'd need a straight wrapper for the _bulk_docs endpoint, but with some user-created handling code: http://docs.couchdb.org/en/latest/api/database/bulk-api.html#post--db-_bulk_docs Likely the perfect thing for someone to explore as a plugin. :) Add a _bulk_update handler similar to _update but for bulk document changes --- Key: COUCHDB-1303 URL: https://issues.apache.org/jira/browse/COUCHDB-1303 Project: CouchDB Issue Type: New Feature Reporter: Benjamin Young Labels: api, update_request_handler _update handlers are great (and getting better!) for building RESTful API's inside CouchDB. One limitation I found tonight is that _update can only do a single document at a time. If the API I'm building needs to update multiple docs (in a similar fashion to _bulk_docs), then an outside proxy script is required. It would be ideal to have a _bulk_update handler to allow for the same functionality as _update, but with the ability to insert multiple documents at once. Perhaps the current _update handler API could be extended to support multiple IDs/documents, but a separate API endpoint would be seem reasonable if needed. Thanks for considering this idea. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COUCHDB-348) / should redirect to a human readable page when accessed from a browser
[
https://issues.apache.org/jira/browse/COUCHDB-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843248#comment-13843248
]
Benjamin Young commented on COUCHDB-348:
What if we had this backwards? What if {{/}} defaulted to {{text/html}} unless
the client (aka, CouchDB libraries, HTTP libs, etc) explicitly requested
otherwise?
Browsers, then get Futon/Fauxton handed to them. Clients that hit the {{/}}
resource (mostly Futon Fauxton, I'd recon), then be sure they're asking for
{{application/json}} when hitting that URL. They should be anyway if that's
what they want. :)
That seems like a lighter, faster fix that won't break (m)any things. :) One
hopes...
/ should redirect to a human readable page when accessed from a browser
---
Key: COUCHDB-348
URL: https://issues.apache.org/jira/browse/COUCHDB-348
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Reporter: Chris Anderson
Assignee: Robert Newson
Attachments: COUCHDB_348_01.patch, COUCHDB_348_02.patch,
COUCHDB_348_03.patch, encs.erl
As more people are adopting CouchDB, the number of questions along the lines
of All I see is {couchdb:Welcome,version:0.10.0a773399}, what now?
If this page redirected to /_utils/ (or maybe something more user-focussed)
when the accept headers included html, we could make the first-time user
experience more palatable.
There's some code in COUCHDB-234 that might be helpful here.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (COUCHDB-1954) Clarify Futon/Fauxton transition
[
https://issues.apache.org/jira/browse/COUCHDB-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843249#comment-13843249
]
Benjamin Young commented on COUCHDB-1954:
-
1. we keep them around until the next *major* point release.
2. added some thoughts about {{/}} routing to
[COUCHDB-348|https://issues.apache.org/jira/browse/COUCHDB-348?focusedCommentId=13843248]
3. we should be sure that Fauxton routes those to their new equivalent
(ideally) or en lieu of that, not leave the user stranded (at a broken loading
page or the like), but route them to the default screen (at least).
Just ideas. :)
Clarify Futon/Fauxton transition
Key: COUCHDB-1954
URL: https://issues.apache.org/jira/browse/COUCHDB-1954
Project: CouchDB
Issue Type: Task
Components: Futon
Reporter: Jan Lehnardt
At some point Fauxton will replace Futon. There are a few questions that we
should clarify before we get there:
1. what happens to resources like jquery.js and jquery.couch.js that are
currently in well-known places where CouchApps depend on them?
2. there are several other tickets regarding serving a human readable HTML
page on `/` if the client is clearly a browser. (so people don’t have to type
the `/_utils` manually, how does that play into rolling out Fauxton?
3. cool URLs don’t change: what happens to links into Futon that no longer
work in Fauxton that might be coming in from the docs and other tutorials,
including people’s in-house documentation?
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
[
https://issues.apache.org/jira/browse/COUCHDB-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843302#comment-13843302
]
Benjamin Young commented on COUCHDB-1303:
-
No, this would (if built) handle multiple documents sent in likely in a format
similar to what {{_bulk_docs}} receives and process them in the same manner,
but with a JS function sitting in front.
The wrapper comment was merely about the JS function wrapping the Erlang that
does the {{_bulk_docs}} processing. Nothing more, and certainly with no
requirements outside of CouchDB.
There are ways (like what you describe) to get close to that now, but that
conversation's best for the user's email list. Thanks!
Add a _bulk_update handler similar to _update but for bulk document changes
---
Key: COUCHDB-1303
URL: https://issues.apache.org/jira/browse/COUCHDB-1303
Project: CouchDB
Issue Type: New Feature
Reporter: Benjamin Young
Labels: api, update_request_handler
_update handlers are great (and getting better!) for building RESTful API's
inside CouchDB. One limitation I found tonight is that _update can only do a
single document at a time. If the API I'm building needs to update multiple
docs (in a similar fashion to _bulk_docs), then an outside proxy script is
required. It would be ideal to have a _bulk_update handler to allow for the
same functionality as _update, but with the ability to insert multiple
documents at once.
Perhaps the current _update handler API could be extended to support multiple
IDs/documents, but a separate API endpoint would be seem reasonable if needed.
Thanks for considering this idea.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (COUCHDB-1688) Add query param for returning document on DELETE
Benjamin Young created COUCHDB-1688:
---
Summary: Add query param for returning document on DELETE
Key: COUCHDB-1688
URL: https://issues.apache.org/jira/browse/COUCHDB-1688
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Reporter: Benjamin Young
This would simplify move operations by lowering the number of trips to the
server.
(pseudo HTTP below)
DELETE /db/test_doc?rev=1-whateverinclude_doc=true
200 OK
{ok:true,id:test_doc,rev:6-9663bc6a92dc87488a3bf036cd7f8b2f,
doc: {test:JSON, type:testing}}
With the full doc available in the doc key in the DELETE response, the
developer could simply pull out the value of doc (modify it if needed), and PUT
it back somewhere else.
Currently, this flow looks more like this:
GET /db/test_doc
# keep doc in memory/cache in the app
DELETE /db/test_doc?rev=1-whatever
PUT /db/new_doc_location
# use doc from memory/cache in app
Maybe a nice to have but it would be nice to have. :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1687) HEAD requests on all valid _design/doc endpoints (particularly _update)
Benjamin Young created COUCHDB-1687: --- Summary: HEAD requests on all valid _design/doc endpoints (particularly _update) Key: COUCHDB-1687 URL: https://issues.apache.org/jira/browse/COUCHDB-1687 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Benjamin Young I began building an update handler to catch webhook POSTs, but found that some--like MandrillApp.com--want to be sure the endpoint exists--so they do a HEAD request--before they send content via POST. However, hitting an _update/handler with HEAD generates a 500 Internal Server Error currently. Additionally, I found that _view/* URL's actually send the full content body to HEAD requests. I'd love to see _update _view (and all the others) respond correctly to HEAD requests. Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1687) HEAD requests on all valid _design/doc endpoints (particularly _update)
[ https://issues.apache.org/jira/browse/COUCHDB-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-1687: Description: I began building an update handler to catch webhook POSTs, but found that some (like MandrillApp.com ) want to be sure the endpoint exists (so they do a HEAD request) before they send content via POST. However, hitting an _update/handler with HEAD generates a 500 Internal Server Error currently. Additionally, I found that _view/* URL's actually send the full content body to HEAD requests. I'd love to see _update _view (and all the others) respond correctly to HEAD requests. Thanks! was: I began building an update handler to catch webhook POSTs, but found that some--like MandrillApp.com--want to be sure the endpoint exists--so they do a HEAD request--before they send content via POST. However, hitting an _update/handler with HEAD generates a 500 Internal Server Error currently. Additionally, I found that _view/* URL's actually send the full content body to HEAD requests. I'd love to see _update _view (and all the others) respond correctly to HEAD requests. Thanks! HEAD requests on all valid _design/doc endpoints (particularly _update) --- Key: COUCHDB-1687 URL: https://issues.apache.org/jira/browse/COUCHDB-1687 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Benjamin Young I began building an update handler to catch webhook POSTs, but found that some (like MandrillApp.com ) want to be sure the endpoint exists (so they do a HEAD request) before they send content via POST. However, hitting an _update/handler with HEAD generates a 500 Internal Server Error currently. Additionally, I found that _view/* URL's actually send the full content body to HEAD requests. I'd love to see _update _view (and all the others) respond correctly to HEAD requests. Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-576) Require current update_seq when deleting a database for extra safety.
[ https://issues.apache.org/jira/browse/COUCHDB-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465640#comment-13465640 ] Benjamin Young commented on COUCHDB-576: Use of seq is perhaps silly, but database should really be at least as hard to delete as documents are. Right now it's *much* simpler to annihilate loads of work than it is to destroy a single document. Maybe a random UUID stored per DB used only for delete? Require current update_seq when deleting a database for extra safety. - Key: COUCHDB-576 URL: https://issues.apache.org/jira/browse/COUCHDB-576 Project: CouchDB Issue Type: Improvement Components: Database Core Reporter: Robert Newson Attachments: delete-db-safety-with-tests.patch Require the current update_seq before deleting a database to prevent accidental deletion. DELETE /db2?seq=12 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1472) Futon does not throw need to be admin warning when deleting databases
Benjamin Young created COUCHDB-1472: --- Summary: Futon does not throw need to be admin warning when deleting databases Key: COUCHDB-1472 URL: https://issues.apache.org/jira/browse/COUCHDB-1472 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.2 Environment: homebrew installed CouchDB 1.2.0 on Mac OS X 10.6.8 Reporter: Benjamin Young Priority: Minor The not authorized error is thrown (if you're watching via Firebug or some other browser console), but nothing is displayed in the Futon UI--the spinner (on the in-page dialog) just keeps on a spinnin'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1473) Disable Delete Database button in Futon if user is not an Admin
Benjamin Young created COUCHDB-1473: --- Summary: Disable Delete Database button in Futon if user is not an Admin Key: COUCHDB-1473 URL: https://issues.apache.org/jira/browse/COUCHDB-1473 Project: CouchDB Issue Type: New Feature Components: Futon Reporter: Benjamin Young Priority: Trivial Since you can't delete databases while not logged in as an Admin, it'd be kind to disable the button and possibly display a tool-tip on it stating what the user needs to do to enable it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1472) Futon does not throw need to be admin warning when deleting databases
[ https://issues.apache.org/jira/browse/COUCHDB-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265088#comment-13265088 ] Benjamin Young commented on COUCHDB-1472: - A related fix/approach would be this feature addition: COUCHDB-1473 Futon does not throw need to be admin warning when deleting databases --- Key: COUCHDB-1472 URL: https://issues.apache.org/jira/browse/COUCHDB-1472 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.2 Environment: homebrew installed CouchDB 1.2.0 on Mac OS X 10.6.8 Reporter: Benjamin Young Priority: Minor Labels: futon, javascript, ui The not authorized error is thrown (if you're watching via Firebug or some other browser console), but nothing is displayed in the Futon UI--the spinner (on the in-page dialog) just keeps on a spinnin'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1285) Allow configuration of vendor and module version in the welcome message
[
https://issues.apache.org/jira/browse/COUCHDB-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13106070#comment-13106070
]
Benjamin Young commented on COUCHDB-1285:
-
One suggested change to this patch. Rather than making the key in the welcome
JSON the vendor's name, it should be changed to be a key named vendor with
the full vendor info underneath as an object:
vendor:{name:refuge, version: 2.0.0}
That way in Futon (and elsewhere) the vendor version can be retrieved by
referencing info.vendor.version rather than info.refuge--which would
unnecessarily fork Futon per vendor version).
Thanks.
Allow configuration of vendor and module version in the welcome message
---
Key: COUCHDB-1285
URL: https://issues.apache.org/jira/browse/COUCHDB-1285
Project: CouchDB
Issue Type: Improvement
Reporter: Jan Lehnardt
The patch below allows to configure vendor and module version information
into the GET / welcome message.
E.g.
[vendor]
name = refuge
version = 2.0.0
[modules]
geocouch = 1.2.1
would produce:
{couchdb:Welcome,version:1.2.0,refuge:2.0.0,modules:{geocouch:1.2.1}}
--
--- a/src/couchdb/couch_httpd_misc_handlers.erl
+++ b/src/couchdb/couch_httpd_misc_handlers.erl
@@ -30,9 +30,23 @@
% httpd global handlers
handle_welcome_req(#httpd{method='GET'}=Req, WelcomeMessage) -
+Vendor = case couch_config:get(vendor) of
+ [] - [];
+ Vendor1 - [{
+proplists:get_value(name, Vendor1),
+?l2b(proplists:get_value(version, Vendor1))
+ }]
+end,
+
+Modules = lists:map(fun({Key, Value}) -
+ {Key, ?l2b(Value)}
+end, couch_config:get(modules)),
+
send_json(Req, {[
{couchdb, WelcomeMessage},
-{version, list_to_binary(couch_server:get_version())}
+{version, list_to_binary(couch_server:get_version())}]
+++ Vendor
+++ [{modules, {Modules}}
]});
handle_welcome_req(Req, _) -
send_method_not_allowed(Req, GET,HEAD).
--
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1285) Allow configuration of vendor and module version in the welcome message
[
https://issues.apache.org/jira/browse/COUCHDB-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13106521#comment-13106521
]
Benjamin Young commented on COUCHDB-1285:
-
Precisely. :)
Allow configuration of vendor and module version in the welcome message
---
Key: COUCHDB-1285
URL: https://issues.apache.org/jira/browse/COUCHDB-1285
Project: CouchDB
Issue Type: Improvement
Reporter: Jan Lehnardt
The patch below allows to configure vendor and module version information
into the GET / welcome message.
E.g.
[vendor]
name = refuge
version = 2.0.0
[modules]
geocouch = 1.2.1
would produce:
{couchdb:Welcome,version:1.2.0,refuge:2.0.0,modules:{geocouch:1.2.1}}
--
--- a/src/couchdb/couch_httpd_misc_handlers.erl
+++ b/src/couchdb/couch_httpd_misc_handlers.erl
@@ -30,9 +30,23 @@
% httpd global handlers
handle_welcome_req(#httpd{method='GET'}=Req, WelcomeMessage) -
+Vendor = case couch_config:get(vendor) of
+ [] - [];
+ Vendor1 - [{
+proplists:get_value(name, Vendor1),
+?l2b(proplists:get_value(version, Vendor1))
+ }]
+end,
+
+Modules = lists:map(fun({Key, Value}) -
+ {Key, ?l2b(Value)}
+end, couch_config:get(modules)),
+
send_json(Req, {[
{couchdb, WelcomeMessage},
-{version, list_to_binary(couch_server:get_version())}
+{version, list_to_binary(couch_server:get_version())}]
+++ Vendor
+++ [{modules, {Modules}}
]});
handle_welcome_req(Req, _) -
send_method_not_allowed(Req, GET,HEAD).
--
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1285) Allow configuration of vendor and module version in the welcome message
[
https://issues.apache.org/jira/browse/COUCHDB-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105605#comment-13105605
]
Benjamin Young commented on COUCHDB-1285:
-
+1 for this patch. It does a great job of incorporating current patterns [1]
and opening the door to simple module tracking and version reporting. Great
work, Jan.
[1] http://bigbluehat.cloudant.com/
Allow configuration of vendor and module version in the welcome message
---
Key: COUCHDB-1285
URL: https://issues.apache.org/jira/browse/COUCHDB-1285
Project: CouchDB
Issue Type: Improvement
Reporter: Jan Lehnardt
The patch below allows to configure vendor and module version information
into the GET / welcome message.
E.g.
[vendor]
name = refuge
version = 2.0.0
[modules]
geocouch = 1.2.1
would produce:
{couchdb:Welcome,version:1.2.0,refuge:2.0.0,modules:{geocouch:1.2.1}}
--
--- a/src/couchdb/couch_httpd_misc_handlers.erl
+++ b/src/couchdb/couch_httpd_misc_handlers.erl
@@ -30,9 +30,23 @@
% httpd global handlers
handle_welcome_req(#httpd{method='GET'}=Req, WelcomeMessage) -
+Vendor = case couch_config:get(vendor) of
+ [] - [];
+ Vendor1 - [{
+proplists:get_value(name, Vendor1),
+?l2b(proplists:get_value(version, Vendor1))
+ }]
+end,
+
+Modules = lists:map(fun({Key, Value}) -
+ {Key, ?l2b(Value)}
+end, couch_config:get(modules)),
+
send_json(Req, {[
{couchdb, WelcomeMessage},
-{version, list_to_binary(couch_server:get_version())}
+{version, list_to_binary(couch_server:get_version())}]
+++ Vendor
+++ [{modules, {Modules}}
]});
handle_welcome_req(Req, _) -
send_method_not_allowed(Req, GET,HEAD).
--
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1281) Implement Accept header based content negotiation for the _changes feed
[ https://issues.apache.org/jira/browse/COUCHDB-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-1281: Description: Current continuous and longpoll (and potentially text/event-stream feeds; see COUCHDB-986) are selectable only via a feed query parameter. Ideally, it would be best for these feed types to be made available based on Accept headers sent with the request. Browsers and lesser HTTP clients who don't offer header alteration or addition could fall back to the current feed query param as needed. This addition would allow clients to send Accept: text/event-stream (or other mimetypes) with a _changes feed request and receive the stream body in that mimetype. The current continuous and longpoll responses would need their own registered mimetypes (rather than just text/plain or application/json). These mimetypes could still be used in conjunction with the feed query param. was: Current continuous and longpoll (and potentially text/event-stream feeds; see #COUCHDB-986) are selectable only via a feed query parameter. Ideally, it would be best for these feed types to be made available based on Accept headers sent with the request. Browsers and lesser HTTP clients who don't offer header alteration or addition could fall back to the current feed query param as needed. This addition would allow clients to send Accept: text/event-stream (or other mimetypes) with a _changes feed request and receive the stream body in that mimetype. The current continuous and longpoll responses would need their own registered mimetypes (rather than just text/plain or application/json). These mimetypes could still be used in conjunction with the feed query param. Implement Accept header based content negotiation for the _changes feed --- Key: COUCHDB-1281 URL: https://issues.apache.org/jira/browse/COUCHDB-1281 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Benjamin Young Labels: api, http, httpmime, rest, restful Current continuous and longpoll (and potentially text/event-stream feeds; see COUCHDB-986) are selectable only via a feed query parameter. Ideally, it would be best for these feed types to be made available based on Accept headers sent with the request. Browsers and lesser HTTP clients who don't offer header alteration or addition could fall back to the current feed query param as needed. This addition would allow clients to send Accept: text/event-stream (or other mimetypes) with a _changes feed request and receive the stream body in that mimetype. The current continuous and longpoll responses would need their own registered mimetypes (rather than just text/plain or application/json). These mimetypes could still be used in conjunction with the feed query param. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-986) EventSource feed type for _changes
[ https://issues.apache.org/jira/browse/COUCHDB-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104452#comment-13104452 ] Benjamin Young commented on COUCHDB-986: Good call, Jan. Done: https://issues.apache.org/jira/browse/COUCHDB-1281 EventSource feed type for _changes -- Key: COUCHDB-986 URL: https://issues.apache.org/jira/browse/COUCHDB-986 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Affects Versions: 1.0.1 Reporter: Fedor Indutny Assignee: Jan Lehnardt Attachments: 0001-trunk-eventsource-changes-feed.patch I'll implement EventSource protocol feed for _changes API (feed=eventsource). Some info about it: http://dev.w3.org/html5/eventsource/ It's more useful than websocket, beacause it's read-only. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1281) Implement Accept header based content negotiation for the _changes feed
Implement Accept header based content negotiation for the _changes feed --- Key: COUCHDB-1281 URL: https://issues.apache.org/jira/browse/COUCHDB-1281 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Benjamin Young Current continuous and longpoll (and potentially text/event-stream feeds; see #COUCHDB-986) are selectable only via a feed query parameter. Ideally, it would be best for these feed types to be made available based on Accept headers sent with the request. Browsers and lesser HTTP clients who don't offer header alteration or addition could fall back to the current feed query param as needed. This addition would allow clients to send Accept: text/event-stream (or other mimetypes) with a _changes feed request and receive the stream body in that mimetype. The current continuous and longpoll responses would need their own registered mimetypes (rather than just text/plain or application/json). These mimetypes could still be used in conjunction with the feed query param. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-986) EventSource feed type for _changes
[ https://issues.apache.org/jira/browse/COUCHDB-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103975#comment-13103975 ] Benjamin Young commented on COUCHDB-986: Personally, I'd prefer to see the feed query parameter dropped entirely and have the selection of the feed switch to an Accept header-based (i.e., content negotiation-based) approached. That would allow us to respond correctly to requests for the new text/event-stream content type. A wider ranging change of this kind would of course warrant its own ticket. At any rate, using the temporary experimental-eventsource thing is fine as long as we support both during the transition to the eventsource final option. EventSource feed type for _changes -- Key: COUCHDB-986 URL: https://issues.apache.org/jira/browse/COUCHDB-986 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Affects Versions: 1.0.1 Reporter: Fedor Indutny Assignee: Jan Lehnardt Attachments: 0001-trunk-eventsource-changes-feed.patch I'll implement EventSource protocol feed for _changes API (feed=eventsource). Some info about it: http://dev.w3.org/html5/eventsource/ It's more useful than websocket, beacause it's read-only. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-986) EventSource feed type for _changes
[ https://issues.apache.org/jira/browse/COUCHDB-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102806#comment-13102806 ] Benjamin Young commented on COUCHDB-986: Did anyone happen to snag these patches before that github repo got removed? In future, please submit .patch files here for posterity. :) Also, this should probably use Accept header-based content negation vs. a query param. EventSource feed type for _changes -- Key: COUCHDB-986 URL: https://issues.apache.org/jira/browse/COUCHDB-986 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Affects Versions: 1.0.1 Reporter: Fedor Indutny Assignee: Benoit Chesneau I'll implement EventSource protocol feed for _changes API (feed=eventsource). Some info about it: http://dev.w3.org/html5/eventsource/ It's more useful than websocket, beacause it's read-only. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-605) _update handler doesn't conflict for existing document
[
https://issues.apache.org/jira/browse/COUCHDB-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088260#comment-13088260
]
Benjamin Young commented on COUCHDB-605:
I see this as part of the benefit/usefulness of _update--that you can, as
needed, ignore the MVCC pattern and update a doc regardless of matching _rev's.
However, it should be possible to implement this by comparing a rev query
param to the doc._rev if an existing ID is used. Sadly, (due to issue
COUCHDB-648) it's not possible to send 409 Conflict error by hand (or any
other developer chosen status code).
Basically, _update handlers seem to need a bit more love before they'll be
completely useful for stand-along apps or APIs built on top of CouchDB.
_update handler doesn't conflict for existing document
--
Key: COUCHDB-605
URL: https://issues.apache.org/jira/browse/COUCHDB-605
Project: CouchDB
Issue Type: Bug
Affects Versions: 0.10
Environment: Ubuntu Karmic, in particular it's CouchDB version
0.10.0-0ubuntu3
Reporter: Sergey Shepelev
Assignee: Chris Anderson
design doc:
updates: {
hello: function(doc, req) { doc.value = 100500; return [doc, 'foo
bar']; }
}
$ curl -X PUT --data-binary @- http://localhost:5984/shkaf/client:foo EOF
{_id:client:foo}
EOF
{ok:true,id:client:foo,rev:1-967a00dff5e02add41819138abb3284d}
$ curl -X PUT --data-binary @-
http://localhost:5984/shkaf/_design/client/_update/hello/client:foo?A=B EOF
{_id: client:foo}
EOF
foo bar
And it really updated the document.
What i expected here is error: conflict because document with such _id
already existed and i didn't provide _rev to _update handler.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-985) Update handlers can make documents with blank _id
[
https://issues.apache.org/jira/browse/COUCHDB-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088264#comment-13088264
]
Benjamin Young commented on COUCHDB-985:
This is still a problem in the latest trunk and it removes the ability to
DELETE the doc via /{db}/{doc} as {doc} can't == as you'd then delete the DB.
Update handlers can make documents with blank _id
-
Key: COUCHDB-985
URL: https://issues.apache.org/jira/browse/COUCHDB-985
Project: CouchDB
Issue Type: Bug
Components: Database Core, JavaScript View Server
Affects Versions: 1.0.1
Environment: OS X, built using brew
Reporter: Nick Fisher
Priority: Minor
Make the following update handler:
'''
function(doc, req){
return [{}, 'done\n'];
}
'''
Then do a POST to the handler. You will then have a document with a blank _id.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1215) Improve _config error handling by validating certain (if not all) values based on their keys
Improve _config error handling by validating certain (if not all) values based
on their keys
Key: COUCHDB-1215
URL: https://issues.apache.org/jira/browse/COUCHDB-1215
Project: CouchDB
Issue Type: Improvement
Components: Futon, HTTP Interface
Affects Versions: 1.1
Reporter: Benjamin Young
Priority: Minor
When saving values via Futon or the HTTP API, it's easy to put in values that
are invalid and could make CouchDB unbootable. Some level of validation here
would save the day in most cases or the disposal of the incorrect values with a
log message (rather than preventing startup).
In my case, I'd added just http://google.com/; to the value of the _google
key in the httpd_global_handlers section and that prevented CouchDB from
starting. The ever fabulous Paul Davis pointed out my error and it was easy
enough to fix by altering the value in the .ini file to be the correct
value...which is: {couch_httpd_proxy, handle_proxy_req,
http://www.google.com;}
In the case of these httpd_global_handlers a simple check that it's an Erlang
tuple with at least two terms would be a simple check that would have kept my
CouchDB instance up.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1145) As a CouchApp developer, I'd like access to a listing of local-only (_local) docs.
As a CouchApp developer, I'd like access to a listing of local-only (_local)
docs.
--
Key: COUCHDB-1145
URL: https://issues.apache.org/jira/browse/COUCHDB-1145
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Reporter: Benjamin Young
I'm seeing an increased use of _local/{doc} in CouchApps for storing local
config data that should not be replicated for security reasons or because they
want it to stay local for instance identification.
Currently, those docs can only be retrieved if the app developer knows they're
there--which may be fine for the app developer. However, if the local
user/admin who installed the CouchApp wanted to see the data stored, they
can't--at least not via Futon...they'd have to use some pretty complex Erlang
via the Erlang shell (re: davisp).
Please consider making _local doc listing available to the REST API, so it can
be exposed to Futon (and others).
Thanks.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1131) Port Futon2 local replication target work to Futon
[ https://issues.apache.org/jira/browse/COUCHDB-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022173#comment-13022173 ] Benjamin Young commented on COUCHDB-1131: - These have been added to Futon 2, fwiw: https://github.com/BigBlueHat/couchdb/commits/sammy/ Port Futon2 local replication target work to Futon -- Key: COUCHDB-1131 URL: https://issues.apache.org/jira/browse/COUCHDB-1131 Project: CouchDB Issue Type: New Feature Components: Futon Reporter: Sam Bisbee Priority: Minor Attachments: 0001-Adding-jQuery-UI-1.8.11-JS-and-CSS-for-just-the-auto.patch, 0002-Replacing-replication-s-local-target-dropdown-with-a.patch Futon2 currently has a patch that makes the replication target into a text input, using jQuery UI's autocomplete widget to still provide the all databases functionality. If the database doesn't exist, then the user is prompted to see if they want it created with a JS confirm() prompt. If they do, then the create_target replication option is set to true. This will be a port of this Futon2 pull request: https://github.com/BigBlueHat/couchdb/pull/1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1131) Port Futon2 local replication target work to Futon
[ https://issues.apache.org/jira/browse/COUCHDB-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022371#comment-13022371 ] Benjamin Young commented on COUCHDB-1131: - +1 This is definitely an improvement. I've also pulled it into Futon2 (via the pull request above), fwiw. Port Futon2 local replication target work to Futon -- Key: COUCHDB-1131 URL: https://issues.apache.org/jira/browse/COUCHDB-1131 Project: CouchDB Issue Type: New Feature Components: Futon Reporter: Sam Bisbee Priority: Minor Attachments: 0001-Adding-jQuery-UI-1.8.11-JS-and-CSS-for-just-the-auto.patch, 0002-Replacing-replication-s-local-target-dropdown-with-a.patch, 0003-NOTICE-and-LICENSE-updates-for-inclusion-of-jQuery-U.patch Futon2 currently has a patch that makes the replication target into a text input, using jQuery UI's autocomplete widget to still provide the all databases functionality. If the database doesn't exist, then the user is prompted to see if they want it created with a JS confirm() prompt. If they do, then the create_target replication option is set to true. This will be a port of this Futon2 pull request: https://github.com/BigBlueHat/couchdb/pull/1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-951) Test DB upgrade for 1.0.x to 1.1.0
[ https://issues.apache.org/jira/browse/COUCHDB-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013011#comment-13013011 ] Benjamin Young commented on COUCHDB-951: Ran the script, and got UPGRADE PASSED System Stats: Mac OS X 10.6.6 on a Macbook Air 2.13 GHz (core2) w/4GB SSD Test DB upgrade for 1.0.x to 1.1.0 -- Key: COUCHDB-951 URL: https://issues.apache.org/jira/browse/COUCHDB-951 Project: CouchDB Issue Type: Test Affects Versions: 1.1 Reporter: Robert Newson Assignee: Robert Newson Fix For: 1.1 As the on-disk format has changed (for Range header support for attachments) extensive testing of db upgrades should be performed. The Range upgrade occurs on compaction, so it should suffice to; 1) create a db with 1.0.x 2) upgrade to 1.1.0 3) compact 4) verify db I will be working on scripts to automate as much as possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COUCHDB-1041) Send replication conflict (are you replicating to yourself?) error back
Send replication conflict (are you replicating to yourself?) error back - Key: COUCHDB-1041 URL: https://issues.apache.org/jira/browse/COUCHDB-1041 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 1.1, 1.0.1 Reporter: Benjamin Young Priority: Minor I have three local CouchDB instances on various ports (differing versions). I accidently entered the port number for the instance I was replicating *to* in the *from* field, so the replication would have been to and from the same database. CouchDB doesn't currently send that error to the client, though it does output this in the logs: checkpoint failure: conflict (are you replicating to yourself?) It would be handy (at least for Futon) to have that information in either the response body or in the header. The log error message does include conflict in the wording, so perhaps a 409 Conflict error message is in order. Happy to provide a patch if 409 is the way to go. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-950) Futon2!
[ https://issues.apache.org/jira/browse/COUCHDB-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986485#action_12986485 ] Benjamin Young commented on COUCHDB-950: Because it was so wonderfully easy to do, I've made Futon2 a CouchApp: https://github.com/BigBlueHat/couchdb/commit/7fa137a60661afe515a00a02fb52d56ecb564c0a There's basic setup information in the README: https://github.com/BigBlueHat/couchdb/tree/sammy/share/futon The primary advantage is that web developers who aren't interested in building the latest CouchDB but who would like to contribute to Futon, may now do so without needing to compile CouchDB. Please Note: I am not proposing that the CouchApp be used in place of _utils/ but simply as a development option for developers who are primarily interested in the client-side aspects of CouchDB (and who likely don't want to take the time to build another instance of CouchDB to do so). This also provides the opportunity for others to dog food Futon 2 along side _utils with out significant alteration to their environment. Hope it's useful. :) Futon2! --- Key: COUCHDB-950 URL: https://issues.apache.org/jira/browse/COUCHDB-950 Project: CouchDB Issue Type: New Feature Environment: All. Reporter: mikeal Attachments: futon2.diff This is a complete rewrite of Futon as a single page app using sammy.js. I've been working on it for some time at https://github.com/mikeal/couchdb/tree/sammy Changes - - Everything expect for session.html is loaded dynamically as a content replace to index.html. - The total amount of javascript loaded at any time is about 1/3, a combination of removing abstractions and some very large jQuery plugins. - Load times for all pages is dramatically reduced - URL structure of futon now mimics the CouchDB REST API except at #/ - An intended side-effect of the new URL structure is that the button to pull up the current page as a request to CouchDB works *everywhere* - Unified error handling (Any network or HTTP error is now displayed as error bubbled at the top of the page content) - All paging is now done inline making the loads faster and more usable - Many dialogs have been removed in favor of simpler UI elements (as a side effect it's more mobile friendly). - All dbinfo is in database page as well as the total size calculated from the db size and the size of all the views. - db page includes support for start/end queries against _all_docs - Stats page now includes all info from _stats - added _changes page - Cleaned up loading of test files (faster and parallelized now). The test are now automatically sorted alpha regardless of the order in the array definition. - New Document viewer/editor -- In-line auto-save -- Full revision information and restoration -- New UI shows all arrays and objects as initially collapsed to improve handling of large docs. -- Load time, even with incredibly large objects, is almost instance (a combination of not using a table and only creating elements in the expanded view after you click to expand them) - New Views Page -- Emphasis is now on building queries with building view functions a secondary function. -- All view options exposed, options now allowed are disabled. -- All queries can be built in this view and then -- Creating new views, and editing views, is now a process of editing and saving design documents, all usage of temp views has been removed. -- include_docs expand/collapse when in query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-1038) futon.js setting $.couch.urlPrefix=.. makes it impossible to use futon as a couchapp in any db
[ https://issues.apache.org/jira/browse/COUCHDB-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986489#action_12986489 ] Benjamin Young commented on COUCHDB-1038: - This comment on the Futon2 ticket (#950) may be of interest: https://issues.apache.org/jira/browse/COUCHDB-950?focusedCommentId=12986485page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12986485 Would love your input/contributions if you're interested and have time. Thanks. futon.js setting $.couch.urlPrefix=.. makes it impossible to use futon as a couchapp in any db Key: COUCHDB-1038 URL: https://issues.apache.org/jira/browse/COUCHDB-1038 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.0.2 Environment: futon from 1.0.2 as couchapp on CouchDB 1.0.1 on Mac OS X 10.6 Reporter: Jan Harmsen Priority: Minor futon.js setting $.couch.urlPrefix=.. makes it impossible to use futon as a couchapp in any db one needs to set $.couch.urlPrefix= in futon.js for using futon as a normal couchapp (i.e. in any DB) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-950) Futon2!
[ https://issues.apache.org/jira/browse/COUCHDB-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12984751#action_12984751 ] Benjamin Young commented on COUCHDB-950: I've picked up with Mikeal's work and have been hacking on Futon2 in my CouchDB Github repo: https://github.com/bigbluehat/couchdb I'm sure there's still plenty more to address, so I won't submit a patch just yet. So far, though, I've been working on making the API show through the UI where possible (in the Title, bread crumbs), I've added some tabs when you're inside the database area, and a database drop down for switching dbs while in the database area. I'll not my post my whole list of hopes and dreams here, but if anyone's interested in forking and collaborating, I'd love to the help. Feedback welcome. Thanks, Benjamin Futon2! --- Key: COUCHDB-950 URL: https://issues.apache.org/jira/browse/COUCHDB-950 Project: CouchDB Issue Type: New Feature Environment: All. Reporter: mikeal Attachments: futon2.diff This is a complete rewrite of Futon as a single page app using sammy.js. I've been working on it for some time at https://github.com/mikeal/couchdb/tree/sammy Changes - - Everything expect for session.html is loaded dynamically as a content replace to index.html. - The total amount of javascript loaded at any time is about 1/3, a combination of removing abstractions and some very large jQuery plugins. - Load times for all pages is dramatically reduced - URL structure of futon now mimics the CouchDB REST API except at #/ - An intended side-effect of the new URL structure is that the button to pull up the current page as a request to CouchDB works *everywhere* - Unified error handling (Any network or HTTP error is now displayed as error bubbled at the top of the page content) - All paging is now done inline making the loads faster and more usable - Many dialogs have been removed in favor of simpler UI elements (as a side effect it's more mobile friendly). - All dbinfo is in database page as well as the total size calculated from the db size and the size of all the views. - db page includes support for start/end queries against _all_docs - Stats page now includes all info from _stats - added _changes page - Cleaned up loading of test files (faster and parallelized now). The test are now automatically sorted alpha regardless of the order in the array definition. - New Document viewer/editor -- In-line auto-save -- Full revision information and restoration -- New UI shows all arrays and objects as initially collapsed to improve handling of large docs. -- Load time, even with incredibly large objects, is almost instance (a combination of not using a table and only creating elements in the expanded view after you click to expand them) - New Views Page -- Emphasis is now on building queries with building view functions a secondary function. -- All view options exposed, options now allowed are disabled. -- All queries can be built in this view and then -- Creating new views, and editing views, is now a process of editing and saving design documents, all usage of temp views has been removed. -- include_docs expand/collapse when in query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-973) Return 410 when GETing a previously deleted document (rather than 404)
[ https://issues.apache.org/jira/browse/COUCHDB-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12981282#action_12981282 ] Benjamin Young commented on COUCHDB-973: From rfc2616: A response received with a status code of 200, 203, 206, 300, 301 or 410 MAY be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control directive prohibits caching. Cache-Control is current set to must-revalidate, so... When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. (I.e., the cache MUST do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response is stale.) So, in the spirit of future and unexpected innovation, I'd like to see this included...but I'm happy to discuss it further. Also, there are additional uses for 410 if it were available on /db URL's as well--but I'm not sure if CouchDB keeps that information around. Return 410 when GETing a previously deleted document (rather than 404) -- Key: COUCHDB-973 URL: https://issues.apache.org/jira/browse/COUCHDB-973 Project: CouchDB Issue Type: Bug Reporter: Benjamin Young Priority: Trivial Attachments: 410.patch When you GET a nonexistent doc you get (as you should) a 404 Not Found error. However, if you GET a document that has previously existed you also get the 404 response. It would be more informative (IMO) for the 410 Gone response code to be used. 410 Gone's intention is for exactly this use case, and it could have some value to CouchDB developers who need to know the document did exist. CouchDB is already half way there as in the body of the 404 response it does state that the document did exist (at least prior to compaction), so outputing a 410 (again, prior to compaction) would hopefully be a trivial patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-147) Make Futon an Extensible/Embedabble Authoring Tool
[ https://issues.apache.org/jira/browse/COUCHDB-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12981312#action_12981312 ] Benjamin Young commented on COUCHDB-147: FWIW: Futon as a CouchApp: https://github.com/darosh/futon Make Futon an Extensible/Embedabble Authoring Tool -- Key: COUCHDB-147 URL: https://issues.apache.org/jira/browse/COUCHDB-147 Project: CouchDB Issue Type: Wish Components: Futon Reporter: Rob Evans For folks wishing to build stackless web applications on top of couchdb, futon is good place to start. In my own work, I've attempted to integrate futon into my application to create an app that hosts its own development environment much the same way as wikis combine authoring as well as presentation. I believe the seaside smalltalk framework takes this approach as well. Please consider evolving futon to become more extensible and embeddable. stackless web application : An application that requires little more than HTTP, HTML, and JavaScript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-1026) Database names are not encoded in the rewriter
Database names are not encoded in the rewriter
--
Key: COUCHDB-1026
URL: https://issues.apache.org/jira/browse/COUCHDB-1026
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0.1
Reporter: Benjamin Young
If a database includes special characters (such as / forward slash), then the
rewriter will fail to find the correct database and send a 404 error:
{error:not_found,reason:no_db_file}
The attached patch simply adds a url_encode step around DbName.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-1026) Database names are not encoded in the rewriter
[
https://issues.apache.org/jira/browse/COUCHDB-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Young updated COUCHDB-1026:
Attachment: encode_db_name_in_rewriter.patch
Database names are not encoded in the rewriter
--
Key: COUCHDB-1026
URL: https://issues.apache.org/jira/browse/COUCHDB-1026
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0.1
Reporter: Benjamin Young
Attachments: encode_db_name_in_rewriter.patch
If a database includes special characters (such as / forward slash), then
the rewriter will fail to find the correct database and send a 404 error:
{error:not_found,reason:no_db_file}
The attached patch simply adds a url_encode step around DbName.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-973) Return 410 when GETing a previously deleted document (rather than 404)
[ https://issues.apache.org/jira/browse/COUCHDB-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-973: --- Attachment: 410.patch Return 410 when GETing a previously deleted document (rather than 404) -- Key: COUCHDB-973 URL: https://issues.apache.org/jira/browse/COUCHDB-973 Project: CouchDB Issue Type: Bug Reporter: Benjamin Young Priority: Trivial Attachments: 410.patch When you GET a nonexistent doc you get (as you should) a 404 Not Found error. However, if you GET a document that has previously existed you also get the 404 response. It would be more informative (IMO) for the 410 Gone response code to be used. 410 Gone's intention is for exactly this use case, and it could have some value to CouchDB developers who need to know the document did exist. CouchDB is already half way there as in the body of the 404 response it does state that the document did exist (at least prior to compaction), so outputing a 410 (again, prior to compaction) would hopefully be a trivial patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-1014) Make prepareUserDoc a public method of $.couch
Make prepareUserDoc a public method of $.couch -- Key: COUCHDB-1014 URL: https://issues.apache.org/jira/browse/COUCHDB-1014 Project: CouchDB Issue Type: Bug Components: Futon Reporter: Benjamin Young Priority: Trivial Attachments: prepareUserDoc.patch The prepareUserDoc function is a helpful feature of jquery.couch.js, but it's currently a private/hidden function. This patch makes it a public method of $.couch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-1014) Make prepareUserDoc a public method of $.couch
[ https://issues.apache.org/jira/browse/COUCHDB-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-1014: Attachment: prepareUserDoc.patch Make prepareUserDoc a public method of $.couch -- Key: COUCHDB-1014 URL: https://issues.apache.org/jira/browse/COUCHDB-1014 Project: CouchDB Issue Type: Bug Components: Futon Reporter: Benjamin Young Priority: Trivial Attachments: prepareUserDoc.patch The prepareUserDoc function is a helpful feature of jquery.couch.js, but it's currently a private/hidden function. This patch makes it a public method of $.couch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-1015) Add Change Password feature to Futon
[ https://issues.apache.org/jira/browse/COUCHDB-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-1015: Attachment: change_password_in_futon.patch Add Change Password feature to Futon -- Key: COUCHDB-1015 URL: https://issues.apache.org/jira/browse/COUCHDB-1015 Project: CouchDB Issue Type: New Feature Components: Futon Reporter: Benjamin Young Attachments: change_password_in_futon.patch This patch allows users to change their passwords from a link in the sidebar of Futon. It depends on the prepeareUserDoc patch attached to #1014. Passwords can be change for both _user members and _admin users. Once the password is change the user is re-authenticated with the same password without needing to login again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-972) Unauthorized requests with(out) Accept: */* get different status codes
Unauthorized requests with(out) Accept: */* get different status codes -- Key: COUCHDB-972 URL: https://issues.apache.org/jira/browse/COUCHDB-972 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface Affects Versions: 1.0.1 Reporter: Benjamin Young Priority: Minor Sending a GET request without an Accept header set returns a 302 Found status which redirects to the Futon's login page. Sending a GET request with an Accept: */* (which is conceptually the same) returns a 401 (as does setting Accept to anything else: application/json, etc). The 401 code is the prefered response, but the 302 is in use to load the HTML/JS-based login forms in Futon. The options I can see to fix this are: 1. Return 302 if Accept is set to */*, but return 401 for application/json (and possibly anything more specific). 2. Return 401 and load the Futon login page/system as the response body--some browsers/clients may still load the HTTP Auth form in addition to the HTML one in the body of the page. 3. Return 401 and let the browsers HTTP Auth form handle the login process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-972) Unauthorized requests with(out) Accept: */* get different status codes
[ https://issues.apache.org/jira/browse/COUCHDB-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-972: --- Description: Sending a GET request for any URL of private/secured database without an Accept header set returns a 302 Found status which redirects to the Futon's login page. Sending a GET request with an Accept: */* (which is conceptually the same) returns a 401 (as does setting Accept to anything else: application/json, etc). The 401 code is the prefered response, but the 302 is in use to load the HTML/JS-based login forms in Futon. The options I can see to fix this are: 1. Return 302 if Accept is set to */*, but return 401 for application/json (and possibly anything more specific). 2. Return 401 and load the Futon login page/system as the response body--some browsers/clients may still load the HTTP Auth form in addition to the HTML one in the body of the page. 3. Return 401 and let the browsers HTTP Auth form handle the login process. was: Sending a GET request without an Accept header set returns a 302 Found status which redirects to the Futon's login page. Sending a GET request with an Accept: */* (which is conceptually the same) returns a 401 (as does setting Accept to anything else: application/json, etc). The 401 code is the prefered response, but the 302 is in use to load the HTML/JS-based login forms in Futon. The options I can see to fix this are: 1. Return 302 if Accept is set to */*, but return 401 for application/json (and possibly anything more specific). 2. Return 401 and load the Futon login page/system as the response body--some browsers/clients may still load the HTTP Auth form in addition to the HTML one in the body of the page. 3. Return 401 and let the browsers HTTP Auth form handle the login process. Unauthorized requests with(out) Accept: */* get different status codes -- Key: COUCHDB-972 URL: https://issues.apache.org/jira/browse/COUCHDB-972 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface Affects Versions: 1.0.1 Reporter: Benjamin Young Priority: Minor Sending a GET request for any URL of private/secured database without an Accept header set returns a 302 Found status which redirects to the Futon's login page. Sending a GET request with an Accept: */* (which is conceptually the same) returns a 401 (as does setting Accept to anything else: application/json, etc). The 401 code is the prefered response, but the 302 is in use to load the HTML/JS-based login forms in Futon. The options I can see to fix this are: 1. Return 302 if Accept is set to */*, but return 401 for application/json (and possibly anything more specific). 2. Return 401 and load the Futon login page/system as the response body--some browsers/clients may still load the HTTP Auth form in addition to the HTML one in the body of the page. 3. Return 401 and let the browsers HTTP Auth form handle the login process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-973) Return 410 when GETing a previously deleted document (rather than 404)
Return 410 when GETing a previously deleted document (rather than 404) -- Key: COUCHDB-973 URL: https://issues.apache.org/jira/browse/COUCHDB-973 Project: CouchDB Issue Type: Bug Reporter: Benjamin Young Priority: Trivial When you GET a nonexistent doc you get (as you should) a 404 Not Found error. However, if you GET a document that has previously existed you also get the 404 response. It would be more informative (IMO) for the 410 Gone response code to be used. 410 Gone's intention is for exactly this use case, and it could have some value to CouchDB developers who need to know the document did exist. CouchDB is already half way there as in the body of the 404 response it does state that the document did exist (at least prior to compaction), so outputing a 410 (again, prior to compaction) would hopefully be a trivial patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-972) Unauthorized requests with(out) Accept: */* get different status codes
[ https://issues.apache.org/jira/browse/COUCHDB-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-972: --- Remaining Estimate: 0h Original Estimate: 0h Unauthorized requests with(out) Accept: */* get different status codes -- Key: COUCHDB-972 URL: https://issues.apache.org/jira/browse/COUCHDB-972 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface Affects Versions: 1.0.1 Reporter: Benjamin Young Assignee: Filipe Manana Priority: Minor Original Estimate: 0h Remaining Estimate: 0h Sending a GET request for any URL of private/secured database without an Accept header set returns a 302 Found status which redirects to the Futon's login page. Sending a GET request with an Accept: */* (which is conceptually the same) returns a 401 (as does setting Accept to anything else: application/json, etc). The 401 code is the prefered response, but the 302 is in use to load the HTML/JS-based login forms in Futon. The options I can see to fix this are: 1. Return 302 if Accept is set to */*, but return 401 for application/json (and possibly anything more specific). 2. Return 401 and load the Futon login page/system as the response body--some browsers/clients may still load the HTTP Auth form in addition to the HTML one in the body of the page. 3. Return 401 and let the browsers HTTP Auth form handle the login process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-972) Unauthorized requests with(out) Accept: */* get different status codes
[ https://issues.apache.org/jira/browse/COUCHDB-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965821#action_12965821 ] Benjamin Young commented on COUCHDB-972: Important Note about option #1: Futon's JS doesn't currently send an Accept header, and so (if option #1 is implemented) would begin getting 302 responses rather than 401's which would break the private database notifications. Instead, the Futon would output the HTML from the destination of the 302. Unauthorized requests with(out) Accept: */* get different status codes -- Key: COUCHDB-972 URL: https://issues.apache.org/jira/browse/COUCHDB-972 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface Affects Versions: 1.0.1 Reporter: Benjamin Young Assignee: Filipe Manana Priority: Minor Original Estimate: 0h Remaining Estimate: 0h Sending a GET request for any URL of private/secured database without an Accept header set returns a 302 Found status which redirects to the Futon's login page. Sending a GET request with an Accept: */* (which is conceptually the same) returns a 401 (as does setting Accept to anything else: application/json, etc). The 401 code is the prefered response, but the 302 is in use to load the HTML/JS-based login forms in Futon. The options I can see to fix this are: 1. Return 302 if Accept is set to */*, but return 401 for application/json (and possibly anything more specific). 2. Return 401 and load the Futon login page/system as the response body--some browsers/clients may still load the HTTP Auth form in addition to the HTML one in the body of the page. 3. Return 401 and let the browsers HTTP Auth form handle the login process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-898) Allow provides() to handle raw MIME Type declarations as well as shortcut names
Allow provides() to handle raw MIME Type declarations as well as shortcut names --- Key: COUCHDB-898 URL: https://issues.apache.org/jira/browse/COUCHDB-898 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Affects Versions: 1.0.1 Reporter: Benjamin Young Priority: Minor Fix For: 1.0.2 Right now, provides() only supports the content types declared via registerType() if they're selected using the shortcut names used in main.js (or render.js in trunk). Without a list of those laying around a developer will likely submit a raw MIME Type vs. using the shortcut name. For example, provides(text/calendar, ); currently fails because you need to use: provides(ics, ); More people know about text/calendar than will know to guess the shortcut name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-898) Allow provides() to handle raw MIME Type declarations as well as shortcut names
[ https://issues.apache.org/jira/browse/COUCHDB-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Young updated COUCHDB-898: --- Attachment: provides_reverse_content_type_lookup.diff The attached patch makes them both shortcut names and full MIME Type names usable to provides(). If code uses: provides(text/calendar, ); then the MIME Type list that's included in (shortcut name ics) will be used, just as if the code had been written: provides(ics, ...); This hopefully removes confusion for people only familiar with the MIME Types and who have not yet learned/found the shortcut names. Allow provides() to handle raw MIME Type declarations as well as shortcut names --- Key: COUCHDB-898 URL: https://issues.apache.org/jira/browse/COUCHDB-898 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Affects Versions: 1.0.1 Reporter: Benjamin Young Priority: Minor Fix For: 1.0.2 Attachments: provides_reverse_content_type_lookup.diff Right now, provides() only supports the content types declared via registerType() if they're selected using the shortcut names used in main.js (or render.js in trunk). Without a list of those laying around a developer will likely submit a raw MIME Type vs. using the shortcut name. For example, provides(text/calendar, ); currently fails because you need to use: provides(ics, ); More people know about text/calendar than will know to guess the shortcut name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-895) Improved log() function to handle undefined as well as object's of type xml
Improved log() function to handle undefined as well as object's of type xml
---
Key: COUCHDB-895
URL: https://issues.apache.org/jira/browse/COUCHDB-895
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.0.1, 1.0, 0.11.2, 0.11.1
Reporter: Benjamin Young
Priority: Minor
Fix For: 1.0.2
Currently (1.0.1 and below), if you try log(undefined) in a map/reduce or other
JS function in CouchDB, you'll get a rather verbose stack trace. This patch
casts the message var as a String to avoid that stack trace and output the text
representation of undefined.
Additionally, this patch includes outputting XML objects (build with E4X: new
XML('test /')) as string representations of the entire XML (using
toXMLString()).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-895) Improved log() function to handle undefined as well as object's of type xml
[
https://issues.apache.org/jira/browse/COUCHDB-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Young updated COUCHDB-895:
---
Attachment: log_improvements.diff
Improved log() function to handle undefined as well as object's of type
xml
---
Key: COUCHDB-895
URL: https://issues.apache.org/jira/browse/COUCHDB-895
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 0.11.1, 0.11.2, 1.0, 1.0.1
Reporter: Benjamin Young
Priority: Minor
Fix For: 1.0.2
Attachments: log_improvements.diff
Currently (1.0.1 and below), if you try log(undefined) in a map/reduce or
other JS function in CouchDB, you'll get a rather verbose stack trace. This
patch casts the message var as a String to avoid that stack trace and output
the text representation of undefined.
Additionally, this patch includes outputting XML objects (build with E4X: new
XML('test /')) as string representations of the entire XML (using
toXMLString()).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-818) _bulk_docs throws Attachment name can't start with '_' but document POST API does not
[
https://issues.apache.org/jira/browse/COUCHDB-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Young updated COUCHDB-818:
---
Attachment: 818testcase.diff
I've attached a test case to demonstrate the bug on POST as well as a test case
for _bulk_docs (which is functioning correctly).
_bulk_docs throws Attachment name can't start with '_' but document POST
API does not
---
Key: COUCHDB-818
URL: https://issues.apache.org/jira/browse/COUCHDB-818
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 0.12
Environment: Mac OS X 10.6.3
Reporter: Benjamin Young
Attachments: 818testcase.diff
When inserting documents via the _bulk_docs API, I get this error if I try to
include an attachment that begins with an underscore:
{
error: bad_request
reason: Attachment name can't start with '_'
}
However, if I submit a single doc with an attachment beginning with an
underscore, no such error is generated.
Not sure which one should win, but thought they should be the same. :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-818) _bulk_docs throws Attachment name can't start with '_' but document POST API does not
_bulk_docs throws Attachment name can't start with '_' but document POST API
does not
---
Key: COUCHDB-818
URL: https://issues.apache.org/jira/browse/COUCHDB-818
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 0.12
Environment: Mac OS X 10.6.3
Reporter: Benjamin Young
When inserting documents via the _bulk_docs API, I get this error if I try to
include an attachment that begins with an underscore:
{
error: bad_request
reason: Attachment name can't start with '_'
}
However, if I submit a single doc with an attachment beginning with an
underscore, no such error is generated.
Not sure which one should win, but thought they should be the same. :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-803) Empty body POST's for slightly faster empty document creation
Empty body POST's for slightly faster empty document creation
-
Key: COUCHDB-803
URL: https://issues.apache.org/jira/browse/COUCHDB-803
Project: CouchDB
Issue Type: Wish
Components: HTTP Interface
Affects Versions: 1.0
Reporter: Benjamin Young
Priority: Trivial
This is a super minor request. I think it would be handy if you could create
new documents via POST without a body. You can currently send just {} as the
body to create a new empty document. It'd be a bit faster (coding and packet
wise if you could leave that out).
Again, nothing critical, but might save us all some typing. :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-788) HEAD requests should be logged as HEAD requests, not GET (regression)
HEAD requests should be logged as HEAD requests, not GET (regression) - Key: COUCHDB-788 URL: https://issues.apache.org/jira/browse/COUCHDB-788 Project: CouchDB Issue Type: Bug Components: Database Core, HTTP Interface Affects Versions: 0.12 Environment: Mac OS X 10.6.3 Reporter: Benjamin Young In the latest version of trunk from git (0.12.0a426ab48-git), I've found that HEAD requests are logged as GET requests. In CouchDBX 0.10, the HEAD requests are properly logged as HEAD requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-511) Revision referencing via something like Git's RefLog Shortnames
Revision referencing via something like Git's RefLog Shortnames --- Key: COUCHDB-511 URL: https://issues.apache.org/jira/browse/COUCHDB-511 Project: CouchDB Issue Type: Wish Components: HTTP Interface Reporter: Benjamin Young Priority: Minor Accessing earlier revisions isn't hard, but it would be very handy to reference them via a short hand notation similar to Git's RefLog Shortnames. Perhaps something very similar: http://localhost:5984/db/doc?rev=^ - this would get the previous revision http://localhost:5984/db/doc?rev=^3 - this would get the revision 3 submissions ago Just an idea. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
