[jira] Commented: (COUCHDB-911) Repeating a doc._id in a _bulk_docs request results in erroneous Document conflict error
[
https://issues.apache.org/jira/browse/COUCHDB-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918807#action_12918807
]
Klaus Trainer commented on COUCHDB-911:
---
Trying your example request with CouchDB 1.0.1, I get the following error
message:
{error:bad_request,reason:invalid UTF-8 JSON: \{\\\docs\\\:
[{\\\_id\\\:\\\foo\\\}, {\\\_id\\\,\\\foo\\\}]}\}
When replacing the comma with a colon, I get this result:
{ok:true,id:87bea69a9e2eb988d467183b6100084a,rev:1-ad4b328fcf36f99be059e435c1c32c1c}
Obviously, that's not a CouchDB issue.
Why not just report Cloudant/BigCouch issues that are no CouchDB issues to
Cloudant or rather to the BigCouch project.
- Klaus
Repeating a doc._id in a _bulk_docs request results in erroneous Document
conflict error
--
Key: COUCHDB-911
URL: https://issues.apache.org/jira/browse/COUCHDB-911
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0
Environment: Cloudant BigCouch EC2 node
Reporter: Jay Nelson
Priority: Minor
Original Estimate: 48h
Remaining Estimate: 48h
Repeating an _id in a _bulk_docs post data file results in both entries
being reported as document conflict errors. The first occurrence actual
inserts into the database, and only the second occurrence should report a
conflict.
curl -d '{ docs: [ {_id:foo}, {_id,foo} ] }' -H
'Content-Type:application/json' -X POST
http://appadvice.cloudant.com/foo/_bulk_docs
[{id:foo,error:conflict,reason:Document update
conflict.},{id:foo,error:conflict,reason:Document update
conflict.}]
But the database shows that one new document was actually inserted.
Only the second occurrence should report conflict. The first occurrence
should report the _rev property of the newly inserted doc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-911) Repeating a doc._id in a _bulk_docs request results in erroneous Document conflict error
[
https://issues.apache.org/jira/browse/COUCHDB-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918816#action_12918816
]
Klaus Trainer commented on COUCHDB-911:
---
Sorry, I need to currect myself. I was too stupid to correctly specify the
_bulk_docs URL.
I can confirm that the described behavior also applies to CouchDB 1.0.1.
curl http://127.0.0.1:5984/db/_bulk_docs -d '{docs: [{_id:foo},
{_id:foo}]}' -H 'Content-Type: application/json'
[{id:foo,error:conflict,reason:Document update
conflict.},{id:foo,error:conflict,reason:Document update
conflict.}]
However, one of the updates actually succeeded.
Note that when all_or_nothing: true is specified, the result is different.
curl http://127.0.0.1:5984/db/_bulk_docs -d '{all_or_nothing: true, docs:
[{_id:foo}, {_id:foo}]}' -H 'Content-Type: application/json'
[{id:foo,rev:1-967a00dff5e02add41819138abb3284d},{id:foo,rev:1-967a00dff5e02add41819138abb3284d}]
Repeating a doc._id in a _bulk_docs request results in erroneous Document
conflict error
--
Key: COUCHDB-911
URL: https://issues.apache.org/jira/browse/COUCHDB-911
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0
Environment: Cloudant BigCouch EC2 node
Reporter: Jay Nelson
Priority: Minor
Original Estimate: 48h
Remaining Estimate: 48h
Repeating an _id in a _bulk_docs post data file results in both entries
being reported as document conflict errors. The first occurrence actual
inserts into the database, and only the second occurrence should report a
conflict.
curl -d '{ docs: [ {_id:foo}, {_id,foo} ] }' -H
'Content-Type:application/json' -X POST
http://appadvice.cloudant.com/foo/_bulk_docs
[{id:foo,error:conflict,reason:Document update
conflict.},{id:foo,error:conflict,reason:Document update
conflict.}]
But the database shows that one new document was actually inserted.
Only the second occurrence should report conflict. The first occurrence
should report the _rev property of the newly inserted doc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Releasing 1.1
I should remind everyone that the ranges support alters the format of the #att.data field on compaction (it adds the length of the block so we only need read the blocks within the range). While I've tested this to my satisfaction, no automated testing exists for verifying upgrades at this time. B. On Wed, Oct 6, 2010 at 12:09 AM, sgoto samuelg...@gmail.com wrote: On Tue, Oct 5, 2010 at 9:43 AM, Filipe David Manana fdman...@apache.orgwrote: On Tue, Oct 5, 2010 at 5:31 PM, Zachary Zolton zachary.zol...@gmail.com wrote: For those of us not following at the commit level, what differences do you see between 1.0.2 and 1.1? —Zach 3 new major features at least: - HTTP ranges support - replicator DB (_replicator) what does _replicator do ? does it persists the replications settings ? - SSL support (I have some stuff to add fthere or the replicator) On Tue, Oct 5, 2010 at 10:17 AM, Chris Anderson jch...@apache.org wrote: Devs, I think there may be some work to do before 1.1 is released (but maybe not). We should release it before Paul's externals stuff lands, and also not wait for the Sammy.js Futon or Replicator DB UI. Let's start the round-up of patches and tickets that need to go into 1.1. Big things should wait, but simple fixes and refinements are a good idea to bring up. Cheers, Chris -- Chris Anderson http://jchrisa.net http://couch.io -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men. -- f u cn rd ths u cn b a gd prgmr !
[jira] Commented: (COUCHDB-910) Malformed _bulk_docs post data causes a 500 function clause error
[
https://issues.apache.org/jira/browse/COUCHDB-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918922#action_12918922
]
Paul Joseph Davis commented on COUCHDB-910:
---
I'm confused, what part of malformed request causes error is a bug? Or are
you just wanting better error messages?
Malformed _bulk_docs post data causes a 500 function clause error
-
Key: COUCHDB-910
URL: https://issues.apache.org/jira/browse/COUCHDB-910
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0
Environment: Cloudant BigCouch EC2 node
Reporter: Jay Nelson
Priority: Minor
Original Estimate: 48h
Remaining Estimate: 48h
The following two malformed _bulk_docs request result in errors when issued
to Cloudant's BigNode cluster (however, it is fundamentally a CouchDB problem
and should give the same results with a standalone CouchDB):
curl -d '{doc: [] }' -H 'Content-Type:application/json' -X POST
https://appadvice.cloudant.com/foo/_bulk_docs
{error:unknown_error,reason:function_clause}
curl -d '{doc: [{_id:foo}] }' -H 'Content-Type:application/json' -X
POST https://appadvice.cloudant.com/foo/_bulk_docs
{error:unknown_error,reason:function_clause}
In both cases the error is that {docs: [ ... ] } was not used but instead
the keyword doc was used.
The result should be a notification of the error in the data supplied, rather
than crashing the web server.
This is probably a reopening of issues related to COUCHDB-306
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-910) Malformed _bulk_docs post data causes a 500 function clause error
[
https://issues.apache.org/jira/browse/COUCHDB-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918924#action_12918924
]
Paul Joseph Davis commented on COUCHDB-910:
---
Oh, missed that last line. Yeah, should be an easy fix in the bulk docs
handling code.
Malformed _bulk_docs post data causes a 500 function clause error
-
Key: COUCHDB-910
URL: https://issues.apache.org/jira/browse/COUCHDB-910
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0
Environment: Cloudant BigCouch EC2 node
Reporter: Jay Nelson
Priority: Minor
Original Estimate: 48h
Remaining Estimate: 48h
The following two malformed _bulk_docs request result in errors when issued
to Cloudant's BigNode cluster (however, it is fundamentally a CouchDB problem
and should give the same results with a standalone CouchDB):
curl -d '{doc: [] }' -H 'Content-Type:application/json' -X POST
https://appadvice.cloudant.com/foo/_bulk_docs
{error:unknown_error,reason:function_clause}
curl -d '{doc: [{_id:foo}] }' -H 'Content-Type:application/json' -X
POST https://appadvice.cloudant.com/foo/_bulk_docs
{error:unknown_error,reason:function_clause}
In both cases the error is that {docs: [ ... ] } was not used but instead
the keyword doc was used.
The result should be a notification of the error in the data supplied, rather
than crashing the web server.
This is probably a reopening of issues related to COUCHDB-306
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-911) Repeating a doc._id in a _bulk_docs request results in erroneous Document conflict error
[
https://issues.apache.org/jira/browse/COUCHDB-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918927#action_12918927
]
Paul Joseph Davis commented on COUCHDB-911:
---
You've sent two write commands to the database using a single _rev token. This
means you've got a document that's entered into a conflict. Having the first
occurrence in the results *not* be in conflict would be misleading because it
*is* in conflict.
Theoretically we could add a check to reject _bulk_docs updates with duplicate
_id, _rev pairs, but that doesn't seem like a good idea for some reason.
Repeating a doc._id in a _bulk_docs request results in erroneous Document
conflict error
--
Key: COUCHDB-911
URL: https://issues.apache.org/jira/browse/COUCHDB-911
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.0
Environment: Cloudant BigCouch EC2 node
Reporter: Jay Nelson
Priority: Minor
Original Estimate: 48h
Remaining Estimate: 48h
Repeating an _id in a _bulk_docs post data file results in both entries
being reported as document conflict errors. The first occurrence actual
inserts into the database, and only the second occurrence should report a
conflict.
curl -d '{ docs: [ {_id:foo}, {_id,foo} ] }' -H
'Content-Type:application/json' -X POST
http://appadvice.cloudant.com/foo/_bulk_docs
[{id:foo,error:conflict,reason:Document update
conflict.},{id:foo,error:conflict,reason:Document update
conflict.}]
But the database shows that one new document was actually inserted.
Only the second occurrence should report conflict. The first occurrence
should report the _rev property of the newly inserted doc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
design doc weakness (one view fails = all views fail)
Hello devs,
it seems that, on a design document, if there is one view having an error ( for
example Expression does not eval to a function ) than all other views are
then unusable.
It's not critical and not a real bug, but from my (sysadmin) point of view it's
a weakness : one error on one part of the design doc leads to a totally broken
app / couchapp.
Steps to reproduce :
1/ create a new database
2/ Create a design doc :
{
_id: _design/doc1,
views: {
v1: {
map: function() {}
},
v2: {
map: thefunction() {}
}
},
language: javascript
}
3/ Create a doc :
{
_id: doc1
}
4/ Call the v1 view
What's your opinion on this ? Is it worth creating a Jira bug ?
Regards,
Mickael
[jira] Created: (COUCHDB-912) Anonymous Access to Design Docs on private DB's
Anonymous Access to Design Docs on private DB's --- Key: COUCHDB-912 URL: https://issues.apache.org/jira/browse/COUCHDB-912 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Reporter: Dale Harvey Right now people need to go through futon in order to login to couchapps running on private databases, this is a pretty big limitation on the type of couchapps that can be built Propose adding the ability for users to flag the design docs as readable for anonymous users, could be implemented though an attribute on the design doc? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
