[jira] Commented: (COUCHDB-886) Add option to set query options, defined in rewrites.json, as default
[
https://issues.apache.org/jira/browse/COUCHDB-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908620#action_12908620
]
Chris Anderson commented on COUCHDB-886:
I believe came to the conclusion that the feature would look like:
{
"from" : "/general/reports",
"to" : "_list/general_reports/general_reportsByDate",
"query" : {
"descending" : true
} ,
"default" : {
"limit: 51
}
}
where the "query" definition will continue to be mandatory, but the defaults
will be overridable by the client.
I'm not sure I like this... what if instead, the "query" parameter were to
revert to the old behavior (where the client can override it, and for the case
where application designers want to force a particular query, we could have
"enforced-query". with that notion, the previous example would look like this:
{
"from" : "/general/reports",
"to" : "_list/general_reports/general_reportsByDate",
"query" : {
"limit: 51
} ,
"enforced-query" : {
"descending" : true
}
}
The reason to have 2 members is to maintain backwards compatibility with
existing rewrite rules. I also think it is a bit clearer than the alternative.
> Add option to set query options, defined in rewrites.json, as default
> -
>
> Key: COUCHDB-886
> URL: https://issues.apache.org/jira/browse/COUCHDB-886
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Henrik Skupin
>
> With the latest version of CouchDB the URL parameters are not taken into
> account when the rewrites.json file specifies the same ones for the
> appropriate entry. See the following example:
> {
> "from" : "/general/reports",
> "to" : "_list/general_reports/general_reportsByDate",
> "query" : {
> "descending" : true,
> "limit" : 51
> }
> }
> default values: http://mozmill.hskupin.info/general/reports
> custom values: http://mozmill.hskupin.info/general/reports?limit=10
> Whether which URL you are loading, the values from rewrites.json are always
> used. Once the limit entry gets removed from that file, the URL parameter is
> used and 10 rows are displayed.
> As proposed by Benoit query entries should be explicitly allowed to have a
> default value. Otherwise the value from rewrites.json has the priority.
> "query": {
> "key": { "value": ":var", "default": 1}
> }
> Can true be used instead of a number? It could be confusing this way,
> especially when the value is also a number.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-886) Add option to set query options, defined in rewrites.json, as default
Add option to set query options, defined in rewrites.json, as default
-
Key: COUCHDB-886
URL: https://issues.apache.org/jira/browse/COUCHDB-886
Project: CouchDB
Issue Type: Bug
Components: Database Core
Reporter: Henrik Skupin
With the latest version of CouchDB the URL parameters are not taken into
account when the rewrites.json file specifies the same ones for the appropriate
entry. See the following example:
{
"from" : "/general/reports",
"to" : "_list/general_reports/general_reportsByDate",
"query" : {
"descending" : true,
"limit" : 51
}
}
default values: http://mozmill.hskupin.info/general/reports
custom values: http://mozmill.hskupin.info/general/reports?limit=10
Whether which URL you are loading, the values from rewrites.json are always
used. Once the limit entry gets removed from that file, the URL parameter is
used and 10 rows are displayed.
As proposed by Benoit query entries should be explicitly allowed to have a
default value. Otherwise the value from rewrites.json has the priority.
"query": {
"key": { "value": ":var", "default": 1}
}
Can true be used instead of a number? It could be confusing this way,
especially when the value is also a number.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: endkey doesn't obey limit parameter and always returns entries starting with offset 0
Without a transaction it's impossible to insure fully consistent results between pages. startkey + docid is the best we can offer, maybe we should add a simplified API to jquery.couch.js and document best practices. -Mikeal On Sun, Sep 12, 2010 at 9:04 PM, Damien Katz wrote: > It's possible to do it that way, it just needs a way to navigate down the > correct btree nodes and it's pretty cheap. But it ceases to be cheap with > partitioned setups, like in BigCouch. > > Also since the index can change between reads, using offset may produce > values out of order, duplicate or skipped values in your UI. Startkey + > docid generally produces better semantics. > > -Damien > > > On Sep 12, 2010, at 8:21 PM, Randall Leeds wrote: > > > Any reason why we don't put a document count in the btree index to make > skip > > cheap? > >> > >> On Sep 12, 2010, at 9:39 AM, Mikeal Rogers wrote: > >> > >>> For pagination you can use the skip parameter instead of trying to > change > >>> the startkey for each pagination. > >>> > >>> http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options > >>> > >>> ?startkey="foo"&limit=10 > >>> ?startkey="foo"&limit=10&skip=10 > >>> ?startkey="foo"&limit=10&skip=20 > >>> > >> > >> You can but you shouldn't. > >> > >> The right way to do it is to use startkey and limit, as documented here. > >> > >> http://guide.couchdb.org/draft/recipes.html#fast > >> > >>> > >>> On Sun, Sep 12, 2010 at 12:06 AM, Henrik Skupin > > wrote: > >>> > Hi, > > For my current Couch application I'm using pagination to show only 50 > results per page. To navigate back and forward the endkey vs. startkey > parameters are used. While startkey in combination with limit is > working > fine, endkey doesn't return results for [offset(endkey)-limit, > offset(endkey)] but for [0, limit]. This makes pagination impossible > for > > me > and looks like to be a bug. An example you can find here: > > http://mozmill.hskupin.info/general/reports > > After opening the page click 'Next' twice and check the URL of the > 'Previous' link before clicking on it. The endkey parameter will not > be > obeyed and a click on that link causes the first page to be opened. > > The code can be found at: http://github.com/whimboo/mozmill-dashboard > > Is the above problem a known broken behavior and worth filing a bug? > > Thanks, > Henrik > > >> > >
Re: endkey doesn't obey limit parameter and always returns entries starting with offset 0
It's possible to do it that way, it just needs a way to navigate down the correct btree nodes and it's pretty cheap. But it ceases to be cheap with partitioned setups, like in BigCouch. Also since the index can change between reads, using offset may produce values out of order, duplicate or skipped values in your UI. Startkey + docid generally produces better semantics. -Damien On Sep 12, 2010, at 8:21 PM, Randall Leeds wrote: > Any reason why we don't put a document count in the btree index to make skip > cheap? >> >> On Sep 12, 2010, at 9:39 AM, Mikeal Rogers wrote: >> >>> For pagination you can use the skip parameter instead of trying to change >>> the startkey for each pagination. >>> >>> http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options >>> >>> ?startkey="foo"&limit=10 >>> ?startkey="foo"&limit=10&skip=10 >>> ?startkey="foo"&limit=10&skip=20 >>> >> >> You can but you shouldn't. >> >> The right way to do it is to use startkey and limit, as documented here. >> >> http://guide.couchdb.org/draft/recipes.html#fast >> >>> >>> On Sun, Sep 12, 2010 at 12:06 AM, Henrik Skupin > wrote: >>> Hi, For my current Couch application I'm using pagination to show only 50 results per page. To navigate back and forward the endkey vs. startkey parameters are used. While startkey in combination with limit is working fine, endkey doesn't return results for [offset(endkey)-limit, offset(endkey)] but for [0, limit]. This makes pagination impossible for > me and looks like to be a bug. An example you can find here: http://mozmill.hskupin.info/general/reports After opening the page click 'Next' twice and check the URL of the 'Previous' link before clicking on it. The endkey parameter will not be obeyed and a click on that link causes the first page to be opened. The code can be found at: http://github.com/whimboo/mozmill-dashboard Is the above problem a known broken behavior and worth filing a bug? Thanks, Henrik >>
Re: endkey doesn't obey limit parameter and always returns entries starting with offset 0
The document count of the db at the time of view generation or the document count that emits at least one key in the index? Or do you really mean the number of keys in the index? On Sun, Sep 12, 2010 at 8:21 PM, Randall Leeds wrote: > Any reason why we don't put a document count in the btree index to make > skip > cheap? > > > > On Sep 12, 2010, at 9:39 AM, Mikeal Rogers wrote: > > > >> For pagination you can use the skip parameter instead of trying to > change > >> the startkey for each pagination. > >> > >> http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options > >> > >> ?startkey="foo"&limit=10 > >> ?startkey="foo"&limit=10&skip=10 > >> ?startkey="foo"&limit=10&skip=20 > >> > > > > You can but you shouldn't. > > > > The right way to do it is to use startkey and limit, as documented here. > > > > http://guide.couchdb.org/draft/recipes.html#fast > > > >> > >> On Sun, Sep 12, 2010 at 12:06 AM, Henrik Skupin > wrote: > >> > >>> Hi, > >>> > >>> For my current Couch application I'm using pagination to show only 50 > >>> results per page. To navigate back and forward the endkey vs. startkey > >>> parameters are used. While startkey in combination with limit is > working > >>> fine, endkey doesn't return results for [offset(endkey)-limit, > >>> offset(endkey)] but for [0, limit]. This makes pagination impossible > for > me > >>> and looks like to be a bug. An example you can find here: > >>> > >>> http://mozmill.hskupin.info/general/reports > >>> > >>> After opening the page click 'Next' twice and check the URL of the > >>> 'Previous' link before clicking on it. The endkey parameter will not be > >>> obeyed and a click on that link causes the first page to be opened. > >>> > >>> The code can be found at: http://github.com/whimboo/mozmill-dashboard > >>> > >>> Is the above problem a known broken behavior and worth filing a bug? > >>> > >>> Thanks, > >>> Henrik > >>> > > >
Re: endkey doesn't obey limit parameter and always returns entries starting with offset 0
Any reason why we don't put a document count in the btree index to make skip cheap? > > On Sep 12, 2010, at 9:39 AM, Mikeal Rogers wrote: > >> For pagination you can use the skip parameter instead of trying to change >> the startkey for each pagination. >> >> http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options >> >> ?startkey="foo"&limit=10 >> ?startkey="foo"&limit=10&skip=10 >> ?startkey="foo"&limit=10&skip=20 >> > > You can but you shouldn't. > > The right way to do it is to use startkey and limit, as documented here. > > http://guide.couchdb.org/draft/recipes.html#fast > >> >> On Sun, Sep 12, 2010 at 12:06 AM, Henrik Skupin wrote: >> >>> Hi, >>> >>> For my current Couch application I'm using pagination to show only 50 >>> results per page. To navigate back and forward the endkey vs. startkey >>> parameters are used. While startkey in combination with limit is working >>> fine, endkey doesn't return results for [offset(endkey)-limit, >>> offset(endkey)] but for [0, limit]. This makes pagination impossible for me >>> and looks like to be a bug. An example you can find here: >>> >>> http://mozmill.hskupin.info/general/reports >>> >>> After opening the page click 'Next' twice and check the URL of the >>> 'Previous' link before clicking on it. The endkey parameter will not be >>> obeyed and a click on that link causes the first page to be opened. >>> >>> The code can be found at: http://github.com/whimboo/mozmill-dashboard >>> >>> Is the above problem a known broken behavior and worth filing a bug? >>> >>> Thanks, >>> Henrik >>> >
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
Thanks Klaus,
It is somewhat inconvenient way compare to 0.11 single call, but it works!
I still cannot understand why adding a new field to the document with Futon
does not introduce a conflict but attaching a file does?
Cheers
Nikolai
On 13.09.2010, at 00:00, Klaus Trainer wrote:
> You could take all the revs from the _conflicts list, and delete them
> with one _bulk_docs call, e.g.:
>
> curl -vX POST http://127.0.0.1:5984/foobase/_bulk_docs -H 'Content-Type:
> application/json' -d '{"all_or_nothing": true, "docs":[{"_id":"doc",
> "_rev":"2-818ecad858044ee3bb6017e938e98411", "_deleted":true},
> {"_id":"doc", "_rev":"2-3bf9067dce5f550d9bfcdab1217045e7",
> "_deleted":true}, {"_id":"doc",
> "_rev":"2-13839535feb250d3d8290998b8af17c3", "_deleted":true}]}'
>
> - Klaus
>
>
> On Sun, 2010-09-12 at 23:18 +0200, Nikolai Teofilov wrote:
>> But something changed since 0.11 ...
>>
>> In my application I have a master server and several slaves. Each slave pull
>> a document from the master, attach some data and push it back to the master
>> then this document can be updated from another slave and so on ... and this
>> works perfectly in 0.11. I was able to delete the document on the master
>> server with one single delete call.
>> Now each attachment on the slave will introduce a conflict so if I have
>> several attachments on some of the slave machines and if I want to delete
>> after that this document on the master database I have to delete each
>> document revision for each attachment and repeat this for each slave ...
>>
>> Is there a way to delete the document with the whole history with a single
>> API call?
>>
>> Thanks
>> Nikolai
>>
>>
>>
>> On 12.09.2010, at 22:36, Klaus Trainer wrote:
>>
Correct me if I am wrong but there should be message like after the DELETE
operation:
{"error":"conflict","reason":"Document update conflict."}
>>>
>>> ...when you do what?
>>>
but I get:
{"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
Furthermore I don't understand where does the conflict comes in this
situation?
>>>
>>> The point is that when using the _bulk_docs API and "all_or_nothing":
>>> true, documents are written even if the given _rev number doesn't match
>>> the current one. In that case (_rev number doesn't match), you get a new
>>> conflict.
>>>
>>> - Klaus
>>>
>>>
>>> On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
Hi Klaus,
Correct me if I am wrong but there should be message like after the DELETE
operation:
{"error":"conflict","reason":"Document update conflict."}
but I get:
{"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
Furthermore I don't understand where does the conflict comes in this
situation?
Cheers
Nikolai
On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908535#action_12908535
> ]
>
> Klaus Trainer commented on COUCHDB-885:
> ---
>
> Note that the procedure I've previously described will create a conflict:
>
> curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
> {"_id":"doc","_rev":"3-b06fcd1c1c9e0ec7c480ee8aa467bf3b","foo":"bar","_conflicts":["1-4c6114c65e295552ab1019e2b046b10e"]}
>
>> Delete document with attachment fails after replication.
>>
>>
>> Key: COUCHDB-885
>> URL: https://issues.apache.org/jira/browse/COUCHDB-885
>> Project: CouchDB
>> Issue Type: Bug
>> Components: Replication
>> Affects Versions: 1.0.1
>> Environment: Mac OSX, Windows XP, Windows 7
>> Reporter: Nikolai Teofilov
>>
>> Step to reproduce the bug:
>> 1. Make database "test" on a remote couchdb server that reside on a
>> different machine!
>> 2. Create new document: "http://remote-server:5984/test/doc";
>> 3. Create database "test" on the local couchdb server.
>> 4. Trigger pull replication http://remote-server:5984/test ->
>> http://localhost:5984/test
>> 5. Attach a file to the replicated document on the local couchdb server.
>> 6. Trigger push replication http://localhost:5984/test ->
>> http://remote-server:5984/test
>> 7. Delete the replicated document that contain now the attachment on
>> remote database.
>>
>>This operation will delete the last revision of the document (after
>> the replication) but the previous revision of the document (before the
>> replication) still exist in the database.
>> This defect appears only for replications between databases on two
>>>
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
You could take all the revs from the _conflicts list, and delete them
with one _bulk_docs call, e.g.:
curl -vX POST http://127.0.0.1:5984/foobase/_bulk_docs -H 'Content-Type:
application/json' -d '{"all_or_nothing": true, "docs":[{"_id":"doc",
"_rev":"2-818ecad858044ee3bb6017e938e98411", "_deleted":true},
{"_id":"doc", "_rev":"2-3bf9067dce5f550d9bfcdab1217045e7",
"_deleted":true}, {"_id":"doc",
"_rev":"2-13839535feb250d3d8290998b8af17c3", "_deleted":true}]}'
- Klaus
On Sun, 2010-09-12 at 23:18 +0200, Nikolai Teofilov wrote:
> But something changed since 0.11 ...
>
> In my application I have a master server and several slaves. Each slave pull
> a document from the master, attach some data and push it back to the master
> then this document can be updated from another slave and so on ... and this
> works perfectly in 0.11. I was able to delete the document on the master
> server with one single delete call.
> Now each attachment on the slave will introduce a conflict so if I have
> several attachments on some of the slave machines and if I want to delete
> after that this document on the master database I have to delete each
> document revision for each attachment and repeat this for each slave ...
>
> Is there a way to delete the document with the whole history with a single
> API call?
>
> Thanks
> Nikolai
>
>
>
> On 12.09.2010, at 22:36, Klaus Trainer wrote:
>
> >> Correct me if I am wrong but there should be message like after the DELETE
> >> operation:
> >>
> >> {"error":"conflict","reason":"Document update conflict."}
> >
> > ...when you do what?
> >
> >> but I get:
> >>
> >> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
> >>
> >> Furthermore I don't understand where does the conflict comes in this
> >> situation?
> >
> > The point is that when using the _bulk_docs API and "all_or_nothing":
> > true, documents are written even if the given _rev number doesn't match
> > the current one. In that case (_rev number doesn't match), you get a new
> > conflict.
> >
> > - Klaus
> >
> >
> > On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
> >> Hi Klaus,
> >>
> >> Correct me if I am wrong but there should be message like after the DELETE
> >> operation:
> >>
> >> {"error":"conflict","reason":"Document update conflict."}
> >>
> >> but I get:
> >>
> >> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
> >>
> >> Furthermore I don't understand where does the conflict comes in this
> >> situation?
> >>
> >> Cheers
> >> Nikolai
> >>
> >>
> >> On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
> >>
> >>>
> >>> [
> >>> https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908535#action_12908535
> >>> ]
> >>>
> >>> Klaus Trainer commented on COUCHDB-885:
> >>> ---
> >>>
> >>> Note that the procedure I've previously described will create a conflict:
> >>>
> >>> curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
> >>> {"_id":"doc","_rev":"3-b06fcd1c1c9e0ec7c480ee8aa467bf3b","foo":"bar","_conflicts":["1-4c6114c65e295552ab1019e2b046b10e"]}
> >>>
> Delete document with attachment fails after replication.
>
>
> Key: COUCHDB-885
> URL: https://issues.apache.org/jira/browse/COUCHDB-885
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Affects Versions: 1.0.1
> Environment: Mac OSX, Windows XP, Windows 7
> Reporter: Nikolai Teofilov
>
> Step to reproduce the bug:
> 1. Make database "test" on a remote couchdb server that reside on a
> different machine!
> 2. Create new document: "http://remote-server:5984/test/doc";
> 3. Create database "test" on the local couchdb server.
> 4. Trigger pull replication http://remote-server:5984/test ->
> http://localhost:5984/test
> 5. Attach a file to the replicated document on the local couchdb server.
> 6. Trigger push replication http://localhost:5984/test ->
> http://remote-server:5984/test
> 7. Delete the replicated document that contain now the attachment on
> remote database.
>
> This operation will delete the last revision of the document (after
> the replication) but the previous revision of the document (before the
> replication) still exist in the database.
> This defect appears only for replications between databases on two
> different couchdb servers, and only for documents that were updated with
> a new attachment.
> >>>
> >>> --
> >>> This message is automatically generated by JIRA.
> >>> -
> >>> You can reply to this email to add a comment to the issue online.
> >>>
> >>
> >
> >
>
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
But something changed since 0.11 ...
In my application I have a master server and several slaves. Each slave pull a
document from the master, attach some data and push it back to the master then
this document can be updated from another slave and so on ... and this works
perfectly in 0.11. I was able to delete the document on the master server with
one single delete call.
Now each attachment on the slave will introduce a conflict so if I have several
attachments on some of the slave machines and if I want to delete after that
this document on the master database I have to delete each document revision
for each attachment and repeat this for each slave ...
Is there a way to delete the document with the whole history with a single API
call?
Thanks
Nikolai
On 12.09.2010, at 22:36, Klaus Trainer wrote:
>> Correct me if I am wrong but there should be message like after the DELETE
>> operation:
>>
>> {"error":"conflict","reason":"Document update conflict."}
>
> ...when you do what?
>
>> but I get:
>>
>> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
>>
>> Furthermore I don't understand where does the conflict comes in this
>> situation?
>
> The point is that when using the _bulk_docs API and "all_or_nothing":
> true, documents are written even if the given _rev number doesn't match
> the current one. In that case (_rev number doesn't match), you get a new
> conflict.
>
> - Klaus
>
>
> On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
>> Hi Klaus,
>>
>> Correct me if I am wrong but there should be message like after the DELETE
>> operation:
>>
>> {"error":"conflict","reason":"Document update conflict."}
>>
>> but I get:
>>
>> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
>>
>> Furthermore I don't understand where does the conflict comes in this
>> situation?
>>
>> Cheers
>> Nikolai
>>
>>
>> On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908535#action_12908535
>>> ]
>>>
>>> Klaus Trainer commented on COUCHDB-885:
>>> ---
>>>
>>> Note that the procedure I've previously described will create a conflict:
>>>
>>> curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
>>> {"_id":"doc","_rev":"3-b06fcd1c1c9e0ec7c480ee8aa467bf3b","foo":"bar","_conflicts":["1-4c6114c65e295552ab1019e2b046b10e"]}
>>>
Delete document with attachment fails after replication.
Key: COUCHDB-885
URL: https://issues.apache.org/jira/browse/COUCHDB-885
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.1
Environment: Mac OSX, Windows XP, Windows 7
Reporter: Nikolai Teofilov
Step to reproduce the bug:
1. Make database "test" on a remote couchdb server that reside on a
different machine!
2. Create new document: "http://remote-server:5984/test/doc";
3. Create database "test" on the local couchdb server.
4. Trigger pull replication http://remote-server:5984/test ->
http://localhost:5984/test
5. Attach a file to the replicated document on the local couchdb server.
6. Trigger push replication http://localhost:5984/test ->
http://remote-server:5984/test
7. Delete the replicated document that contain now the attachment on
remote database.
This operation will delete the last revision of the document (after
the replication) but the previous revision of the document (before the
replication) still exist in the database.
This defect appears only for replications between databases on two
different couchdb servers, and only for documents that were updated with a
new attachment.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>
>
>
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
> Correct me if I am wrong but there should be message like after the DELETE
> operation:
>
> {"error":"conflict","reason":"Document update conflict."}
...when you do what?
> but I get:
>
> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
>
> Furthermore I don't understand where does the conflict comes in this
> situation?
The point is that when using the _bulk_docs API and "all_or_nothing":
true, documents are written even if the given _rev number doesn't match
the current one. In that case (_rev number doesn't match), you get a new
conflict.
- Klaus
On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
> Hi Klaus,
>
> Correct me if I am wrong but there should be message like after the DELETE
> operation:
>
> {"error":"conflict","reason":"Document update conflict."}
>
> but I get:
>
> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
>
> Furthermore I don't understand where does the conflict comes in this
> situation?
>
> Cheers
> Nikolai
>
>
> On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
>
> >
> >[
> > https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908535#action_12908535
> > ]
> >
> > Klaus Trainer commented on COUCHDB-885:
> > ---
> >
> > Note that the procedure I've previously described will create a conflict:
> >
> > curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
> > {"_id":"doc","_rev":"3-b06fcd1c1c9e0ec7c480ee8aa467bf3b","foo":"bar","_conflicts":["1-4c6114c65e295552ab1019e2b046b10e"]}
> >
> >> Delete document with attachment fails after replication.
> >>
> >>
> >>Key: COUCHDB-885
> >>URL: https://issues.apache.org/jira/browse/COUCHDB-885
> >>Project: CouchDB
> >> Issue Type: Bug
> >> Components: Replication
> >> Affects Versions: 1.0.1
> >>Environment: Mac OSX, Windows XP, Windows 7
> >> Reporter: Nikolai Teofilov
> >>
> >> Step to reproduce the bug:
> >> 1. Make database "test" on a remote couchdb server that reside on a
> >> different machine!
> >> 2. Create new document: "http://remote-server:5984/test/doc";
> >> 3. Create database "test" on the local couchdb server.
> >> 4. Trigger pull replication http://remote-server:5984/test ->
> >> http://localhost:5984/test
> >> 5. Attach a file to the replicated document on the local couchdb server.
> >> 6. Trigger push replication http://localhost:5984/test ->
> >> http://remote-server:5984/test
> >> 7. Delete the replicated document that contain now the attachment on
> >> remote database.
> >>
> >> This operation will delete the last revision of the document (after
> >> the replication) but the previous revision of the document (before the
> >> replication) still exist in the database.
> >> This defect appears only for replications between databases on two
> >> different couchdb servers, and only for documents that were updated with a
> >> new attachment.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
>
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
Hi Klaus,
Correct me if I am wrong but there should be message like after the DELETE
operation:
{"error":"conflict","reason":"Document update conflict."}
but I get:
{"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
Furthermore I don't understand where does the conflict comes in this situation?
Cheers
Nikolai
On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
>
>[
> https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908535#action_12908535
> ]
>
> Klaus Trainer commented on COUCHDB-885:
> ---
>
> Note that the procedure I've previously described will create a conflict:
>
> curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
> {"_id":"doc","_rev":"3-b06fcd1c1c9e0ec7c480ee8aa467bf3b","foo":"bar","_conflicts":["1-4c6114c65e295552ab1019e2b046b10e"]}
>
>> Delete document with attachment fails after replication.
>>
>>
>>Key: COUCHDB-885
>>URL: https://issues.apache.org/jira/browse/COUCHDB-885
>>Project: CouchDB
>> Issue Type: Bug
>> Components: Replication
>> Affects Versions: 1.0.1
>>Environment: Mac OSX, Windows XP, Windows 7
>> Reporter: Nikolai Teofilov
>>
>> Step to reproduce the bug:
>> 1. Make database "test" on a remote couchdb server that reside on a
>> different machine!
>> 2. Create new document: "http://remote-server:5984/test/doc";
>> 3. Create database "test" on the local couchdb server.
>> 4. Trigger pull replication http://remote-server:5984/test ->
>> http://localhost:5984/test
>> 5. Attach a file to the replicated document on the local couchdb server.
>> 6. Trigger push replication http://localhost:5984/test ->
>> http://remote-server:5984/test
>> 7. Delete the replicated document that contain now the attachment on remote
>> database.
>>
>> This operation will delete the last revision of the document (after the
>> replication) but the previous revision of the document (before the
>> replication) still exist in the database.
>> This defect appears only for replications between databases on two different
>> couchdb servers, and only for documents that were updated with a new
>> attachment.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
Re: [feature proposal] make a secure_rewrites filter
On Sun, Sep 12, 2010 at 7:20 PM, J Chris Anderson wrote:
>
> On Sep 12, 2010, at 9:53 AM, Benoit Chesneau wrote:
>
>> Hi all,
>>
>> Sometimes we want to have secure_rewirtes off but only for one db,
>> design doc, for example if we want to write a "futon" like app on top
>> of couchdb. My idea is to set the default like we do know but adding
>> a new setting :
>>
>> [secure_rewrites_filter]
>> {DbName, DdocName}
>>
>> which would take set secure_rewrite to false if default setting is
>> true for this specific ddoc . Before opening a ticket I would lie to
>> discuss this option first here, but it may be really useful in near
>> future.
>
> I think this is good. I'd say it's the best option. Maybe the name should be
> [secure_rewrites_exceptions]
>
> Chris
>
>>
>> - benoit
>
>
Yes indeed exceptions is better in this case. Code is on the way.
- benoit
[jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
[
https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908535#action_12908535
]
Klaus Trainer commented on COUCHDB-885:
---
Note that the procedure I've previously described will create a conflict:
curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
{"_id":"doc","_rev":"3-b06fcd1c1c9e0ec7c480ee8aa467bf3b","foo":"bar","_conflicts":["1-4c6114c65e295552ab1019e2b046b10e"]}
> Delete document with attachment fails after replication.
>
>
> Key: COUCHDB-885
> URL: https://issues.apache.org/jira/browse/COUCHDB-885
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.0.1
> Environment: Mac OSX, Windows XP, Windows 7
>Reporter: Nikolai Teofilov
>
> Step to reproduce the bug:
> 1. Make database "test" on a remote couchdb server that reside on a
> different machine!
> 2. Create new document: "http://remote-server:5984/test/doc";
> 3. Create database "test" on the local couchdb server.
> 4. Trigger pull replication http://remote-server:5984/test ->
> http://localhost:5984/test
> 5. Attach a file to the replicated document on the local couchdb server.
> 6. Trigger push replication http://localhost:5984/test ->
> http://remote-server:5984/test
> 7. Delete the replicated document that contain now the attachment on remote
> database.
>
> This operation will delete the last revision of the document (after the
> replication) but the previous revision of the document (before the
> replication) still exist in the database.
> This defect appears only for replications between databases on two different
> couchdb servers, and only for documents that were updated with a new
> attachment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-883) Wrong document returned due to incorrect URL decoding
[
https://issues.apache.org/jira/browse/COUCHDB-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Muharem Hrnjadovic updated COUCHDB-883:
---
Attachment: logging.diff
I added some logging statements to find out where the a+b -> a b conversion
takes place and came to realize that it happens in handle_request()
(src/couchdb/couch_httpd.erl, line 237) after the 'requested_path_parts' and
'path_parts' are mangled through couch_httpd:unquote() which in turn calls
mochiweb_util:unquote().
A quick experiment confirms that:
$ erl -pz $HOME/src/couchdb/src/mochiweb
Erlang R14A (erts-5.8) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0]
[kernel-poll:false]
Eshell V5.8 (abort with ^G)
1> mochiweb_util:unquote("a+b")
1> .
"a b"
2>
> Wrong document returned due to incorrect URL decoding
> -
>
> Key: COUCHDB-883
> URL: https://issues.apache.org/jira/browse/COUCHDB-883
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.0.1
> Environment: Kubuntu 10.4, Firefox 3.6.8
>Reporter: Taras Puchko
> Attachments: logging.diff
>
>
> I have two documents in my database: "a b" and "a+b". The first can be
> retrieved via "/mydb/a%20b" and the second via "/mydb/a%2Bb".
> When I enter "/mydb/a b" in the browser it automatically encodes it so the
> correct document is returned. But when I enter "/mydb/a+b" the URL is sent
> intact since "+" is a valid character in a path segment according to [1]. The
> problem is that "GET /mydb/a+b" makes CouchDB return the document with id "a
> b" and not the intended one, which is against the URI spec .
> For an informal description of URL encoding one may refer to [2].
> [1]: http://www.ietf.org/rfc/rfc2396.txt
> [2]:
> http://www.lunatech-research.com/archives/2009/02/03/what-every-web-developer-must-know-about-url-encoding
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
[
https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908531#action_12908531
]
Klaus Trainer commented on COUCHDB-885:
---
There is an easier way (only three steps) to get something like that. It
doesn't necessarily involve attachments and replication.
curl -X PUT http://127.0.0.1:5984/foobase/doc -d '{"foo":"bar"}
curl -X POST http://127.0.0.1:5984/foobase/_bulk_docs -H 'Content-Type:
application/json' -d '{"all_or_nothing": true, "docs":[{"_id": "doc",
"_rev":"2-0e871ef78849b0c206091f1a7af6ec41", "foo":"bar"}]}'
curl -X DELETE
http://127.0.0.1:5984/foobase/doc?rev=3-b06fcd1c1c9e0ec7c480ee8aa467bf3b
> Delete document with attachment fails after replication.
>
>
> Key: COUCHDB-885
> URL: https://issues.apache.org/jira/browse/COUCHDB-885
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.0.1
> Environment: Mac OSX, Windows XP, Windows 7
>Reporter: Nikolai Teofilov
>
> Step to reproduce the bug:
> 1. Make database "test" on a remote couchdb server that reside on a
> different machine!
> 2. Create new document: "http://remote-server:5984/test/doc";
> 3. Create database "test" on the local couchdb server.
> 4. Trigger pull replication http://remote-server:5984/test ->
> http://localhost:5984/test
> 5. Attach a file to the replicated document on the local couchdb server.
> 6. Trigger push replication http://localhost:5984/test ->
> http://remote-server:5984/test
> 7. Delete the replicated document that contain now the attachment on remote
> database.
>
> This operation will delete the last revision of the document (after the
> replication) but the previous revision of the document (before the
> replication) still exist in the database.
> This defect appears only for replications between databases on two different
> couchdb servers, and only for documents that were updated with a new
> attachment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
Hi Sebastian! If you try now the same sequence on two databases residing on a one server there is no such a problem so i think this is a replication bug that introduce a conflict like Klaus said, but there shouldn't be a conflict. Cheers, Nikolai On 12.09.2010, at 21:05, Sebastian Cohnen wrote: > I've updated the script and can confirm the issue. > > On 12.09.2010, at 20:47, Nikolai Teofilov wrote: > >> In step 7. delete document on the remote database not on the local. >> >> Cheers >> Nikolai >> >> On 12.09.2010, at 20:25, Sebastian Cohnen (JIRA) wrote: >> >>> >>> [ >>> https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908518#action_12908518 >>> ] >>> >>> Sebastian Cohnen commented on COUCHDB-885: >>> -- >>> >>> I cannot reproduce. >>> >>> But I'm not sure if I understand your steps correctly, so I've written a >>> bash script (see http://www.friendpaste.com/6SrHCU1lseUURuwTJEpCpk) to >>> execute your steps. Could you have a look and verify that I understood your >>> steps correctly? >>> Delete document with attachment fails after replication. Key: COUCHDB-885 URL: https://issues.apache.org/jira/browse/COUCHDB-885 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.0.1 Environment: Mac OSX, Windows XP, Windows 7 Reporter: Nikolai Teofilov Step to reproduce the bug: 1. Make database "test" on a remote couchdb server that reside on a different machine! 2. Create new document: "http://remote-server:5984/test/doc"; 3. Create database "test" on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test -> http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test -> http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This operation will delete the last revision of the document (after the replication) but the previous revision of the document (before the replication) still exist in the database. This defect appears only for replications between databases on two different couchdb servers, and only for documents that were updated with a new attachment. >>> >>> -- >>> This message is automatically generated by JIRA. >>> - >>> You can reply to this email to add a comment to the issue online. >>> >> >
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
I've updated the script and can confirm the issue. On 12.09.2010, at 20:47, Nikolai Teofilov wrote: > In step 7. delete document on the remote database not on the local. > > Cheers > Nikolai > > On 12.09.2010, at 20:25, Sebastian Cohnen (JIRA) wrote: > >> >> [ >> https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908518#action_12908518 >> ] >> >> Sebastian Cohnen commented on COUCHDB-885: >> -- >> >> I cannot reproduce. >> >> But I'm not sure if I understand your steps correctly, so I've written a >> bash script (see http://www.friendpaste.com/6SrHCU1lseUURuwTJEpCpk) to >> execute your steps. Could you have a look and verify that I understood your >> steps correctly? >> >>> Delete document with attachment fails after replication. >>> >>> >>> Key: COUCHDB-885 >>> URL: https://issues.apache.org/jira/browse/COUCHDB-885 >>> Project: CouchDB >>>Issue Type: Bug >>>Components: Replication >>> Affects Versions: 1.0.1 >>> Environment: Mac OSX, Windows XP, Windows 7 >>> Reporter: Nikolai Teofilov >>> >>> Step to reproduce the bug: >>> 1. Make database "test" on a remote couchdb server that reside on a >>> different machine! >>> 2. Create new document: "http://remote-server:5984/test/doc"; >>> 3. Create database "test" on the local couchdb server. >>> 4. Trigger pull replication http://remote-server:5984/test -> >>> http://localhost:5984/test >>> 5. Attach a file to the replicated document on the local couchdb server. >>> 6. Trigger push replication http://localhost:5984/test -> >>> http://remote-server:5984/test >>> 7. Delete the replicated document that contain now the attachment on >>> remote database. >>> >>> This operation will delete the last revision of the document (after the >>> replication) but the previous revision of the document (before the >>> replication) still exist in the database. >>> This defect appears only for replications between databases on two >>> different couchdb servers, and only for documents that were updated with a >>> new attachment. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >
[jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
[ https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908528#action_12908528 ] Sebastian Cohnen commented on COUCHDB-885: -- okay, got an error in my script (I've updated the paste). Now I can confirm the behavior. > Delete document with attachment fails after replication. > > > Key: COUCHDB-885 > URL: https://issues.apache.org/jira/browse/COUCHDB-885 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.0.1 > Environment: Mac OSX, Windows XP, Windows 7 >Reporter: Nikolai Teofilov > > Step to reproduce the bug: > 1. Make database "test" on a remote couchdb server that reside on a > different machine! > 2. Create new document: "http://remote-server:5984/test/doc"; > 3. Create database "test" on the local couchdb server. > 4. Trigger pull replication http://remote-server:5984/test -> > http://localhost:5984/test > 5. Attach a file to the replicated document on the local couchdb server. > 6. Trigger push replication http://localhost:5984/test -> > http://remote-server:5984/test > 7. Delete the replicated document that contain now the attachment on remote > database. > > This operation will delete the last revision of the document (after the > replication) but the previous revision of the document (before the > replication) still exist in the database. > This defect appears only for replications between databases on two different > couchdb servers, and only for documents that were updated with a new > attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
In step 7. delete document on the remote database not on the local. Cheers Nikolai On 12.09.2010, at 20:25, Sebastian Cohnen (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908518#action_12908518 > ] > > Sebastian Cohnen commented on COUCHDB-885: > -- > > I cannot reproduce. > > But I'm not sure if I understand your steps correctly, so I've written a bash > script (see http://www.friendpaste.com/6SrHCU1lseUURuwTJEpCpk) to execute > your steps. Could you have a look and verify that I understood your steps > correctly? > >> Delete document with attachment fails after replication. >> >> >>Key: COUCHDB-885 >>URL: https://issues.apache.org/jira/browse/COUCHDB-885 >>Project: CouchDB >> Issue Type: Bug >> Components: Replication >> Affects Versions: 1.0.1 >>Environment: Mac OSX, Windows XP, Windows 7 >> Reporter: Nikolai Teofilov >> >> Step to reproduce the bug: >> 1. Make database "test" on a remote couchdb server that reside on a >> different machine! >> 2. Create new document: "http://remote-server:5984/test/doc"; >> 3. Create database "test" on the local couchdb server. >> 4. Trigger pull replication http://remote-server:5984/test -> >> http://localhost:5984/test >> 5. Attach a file to the replicated document on the local couchdb server. >> 6. Trigger push replication http://localhost:5984/test -> >> http://remote-server:5984/test >> 7. Delete the replicated document that contain now the attachment on remote >> database. >> >> This operation will delete the last revision of the document (after the >> replication) but the previous revision of the document (before the >> replication) still exist in the database. >> This defect appears only for replications between databases on two different >> couchdb servers, and only for documents that were updated with a new >> attachment. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. >
Re: [jira] Created: (COUCHDB-885) Delete document with attachment fails after replication.
Hi Klaus, I am not sure about the conflict in this situation because if you try to the replication between two databases on one couchdb server there is no conflict and the document is deleted correctly. Cheers Nikolai On 12.09.2010, at 20:13, Klaus Trainer wrote: > Hi Nikolai, > > what you're describing sounds like you've produced a conflict through > replication. Please correct me if I'm wrong. > > When there are several conflicting versions, you can only delete one > version at a time, and the remaining versions will be left untouched > (for good reason). > > - Klaus > > > On Sun, 2010-09-12 at 13:52 -0400, Nikolai Teofilov (JIRA) wrote: >> Delete document with attachment fails after replication. >> >> >> Key: COUCHDB-885 >> URL: https://issues.apache.org/jira/browse/COUCHDB-885 >> Project: CouchDB >> Issue Type: Bug >> Components: Replication >>Affects Versions: 1.0.1 >> Environment: Mac OSX, Windows XP, Windows 7 >>Reporter: Nikolai Teofilov >> >> >> Step to reproduce the bug: >> >> 1. Make database "test" on a remote couchdb server that reside on a >> different machine! >> 2. Create new document: "http://remote-server:5984/test/doc"; >> 3. Create database "test" on the local couchdb server. >> 4. Trigger pull replication http://remote-server:5984/test -> >> http://localhost:5984/test >> 5. Attach a file to the replicated document on the local couchdb server. >> 6. Trigger push replication http://localhost:5984/test -> >> http://remote-server:5984/test >> 7. Delete the replicated document that contain now the attachment on remote >> database. >> >> This will delete last revision of the document after the replication >> but the previous revision of the document before the replication still exist >> in the database. >> >> This defect appears only between replication between databases on two >> different couchdb servers, and it only for documents that has been updated >> with a new attachment. >> > >
[jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
[ https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908518#action_12908518 ] Sebastian Cohnen commented on COUCHDB-885: -- I cannot reproduce. But I'm not sure if I understand your steps correctly, so I've written a bash script (see http://www.friendpaste.com/6SrHCU1lseUURuwTJEpCpk) to execute your steps. Could you have a look and verify that I understood your steps correctly? > Delete document with attachment fails after replication. > > > Key: COUCHDB-885 > URL: https://issues.apache.org/jira/browse/COUCHDB-885 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.0.1 > Environment: Mac OSX, Windows XP, Windows 7 >Reporter: Nikolai Teofilov > > Step to reproduce the bug: > 1. Make database "test" on a remote couchdb server that reside on a > different machine! > 2. Create new document: "http://remote-server:5984/test/doc"; > 3. Create database "test" on the local couchdb server. > 4. Trigger pull replication http://remote-server:5984/test -> > http://localhost:5984/test > 5. Attach a file to the replicated document on the local couchdb server. > 6. Trigger push replication http://localhost:5984/test -> > http://remote-server:5984/test > 7. Delete the replicated document that contain now the attachment on remote > database. > > This operation will delete the last revision of the document (after the > replication) but the previous revision of the document (before the > replication) still exist in the database. > This defect appears only for replications between databases on two different > couchdb servers, and only for documents that were updated with a new > attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COUCHDB-885) Delete document with attachment fails after replication.
Hi Nikolai, what you're describing sounds like you've produced a conflict through replication. Please correct me if I'm wrong. When there are several conflicting versions, you can only delete one version at a time, and the remaining versions will be left untouched (for good reason). - Klaus On Sun, 2010-09-12 at 13:52 -0400, Nikolai Teofilov (JIRA) wrote: > Delete document with attachment fails after replication. > > > Key: COUCHDB-885 > URL: https://issues.apache.org/jira/browse/COUCHDB-885 > Project: CouchDB > Issue Type: Bug > Components: Replication > Affects Versions: 1.0.1 > Environment: Mac OSX, Windows XP, Windows 7 > Reporter: Nikolai Teofilov > > > Step to reproduce the bug: > > 1. Make database "test" on a remote couchdb server that reside on a > different machine! > 2. Create new document: "http://remote-server:5984/test/doc"; > 3. Create database "test" on the local couchdb server. > 4. Trigger pull replication http://remote-server:5984/test -> > http://localhost:5984/test > 5. Attach a file to the replicated document on the local couchdb server. > 6. Trigger push replication http://localhost:5984/test -> > http://remote-server:5984/test > 7. Delete the replicated document that contain now the attachment on remote > database. > > This will delete last revision of the document after the replication > but the previous revision of the document before the replication still exist > in the database. > > This defect appears only between replication between databases on two > different couchdb servers, and it only for documents that has been updated > with a new attachment. >
[jira] Updated: (COUCHDB-885) Delete document with attachment fails after replication.
[ https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolai Teofilov updated COUCHDB-885: - Description: Step to reproduce the bug: 1. Make database "test" on a remote couchdb server that reside on a different machine! 2. Create new document: "http://remote-server:5984/test/doc"; 3. Create database "test" on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test -> http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test -> http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This operation will delete the last revision of the document (after the replication) but the previous revision of the document (before the replication) still exist in the database. This defect appears only for replications between databases on two different couchdb servers, and only for documents that were updated with a new attachment. was: Step to reproduce the bug: 1. Make database "test" on a remote couchdb server that reside on a different machine! 2. Create new document: "http://remote-server:5984/test/doc"; 3. Create database "test" on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test -> http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test -> http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This will delete last revision of the document after the replication but the previous revision of the document before the replication still exist in the database. This defect appears only between replication between databases on two different couchdb servers, and it only for documents that has been updated with a new attachment. > Delete document with attachment fails after replication. > > > Key: COUCHDB-885 > URL: https://issues.apache.org/jira/browse/COUCHDB-885 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 1.0.1 > Environment: Mac OSX, Windows XP, Windows 7 >Reporter: Nikolai Teofilov > > Step to reproduce the bug: > 1. Make database "test" on a remote couchdb server that reside on a > different machine! > 2. Create new document: "http://remote-server:5984/test/doc"; > 3. Create database "test" on the local couchdb server. > 4. Trigger pull replication http://remote-server:5984/test -> > http://localhost:5984/test > 5. Attach a file to the replicated document on the local couchdb server. > 6. Trigger push replication http://localhost:5984/test -> > http://remote-server:5984/test > 7. Delete the replicated document that contain now the attachment on remote > database. > > This operation will delete the last revision of the document (after the > replication) but the previous revision of the document (before the > replication) still exist in the database. > This defect appears only for replications between databases on two different > couchdb servers, and only for documents that were updated with a new > attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-885) Delete document with attachment fails after replication.
Delete document with attachment fails after replication. Key: COUCHDB-885 URL: https://issues.apache.org/jira/browse/COUCHDB-885 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.0.1 Environment: Mac OSX, Windows XP, Windows 7 Reporter: Nikolai Teofilov Step to reproduce the bug: 1. Make database "test" on a remote couchdb server that reside on a different machine! 2. Create new document: "http://remote-server:5984/test/doc"; 3. Create database "test" on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test -> http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test -> http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This will delete last revision of the document after the replication but the previous revision of the document before the replication still exist in the database. This defect appears only between replication between databases on two different couchdb servers, and it only for documents that has been updated with a new attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [feature proposal] make a secure_rewrites filter
On Sep 12, 2010, at 9:53 AM, Benoit Chesneau wrote:
> Hi all,
>
> Sometimes we want to have secure_rewirtes off but only for one db,
> design doc, for example if we want to write a "futon" like app on top
> of couchdb. My idea is to set the default like we do know but adding
> a new setting :
>
> [secure_rewrites_filter]
> {DbName, DdocName}
>
> which would take set secure_rewrite to false if default setting is
> true for this specific ddoc . Before opening a ticket I would lie to
> discuss this option first here, but it may be really useful in near
> future.
I think this is good. I'd say it's the best option. Maybe the name should be
[secure_rewrites_exceptions]
Chris
>
> - benoit
[feature proposal] make a secure_rewrites filter
Hi all,
Sometimes we want to have secure_rewirtes off but only for one db,
design doc, for example if we want to write a "futon" like app on top
of couchdb. My idea is to set the default like we do know but adding
a new setting :
[secure_rewrites_filter]
{DbName, DdocName}
which would take set secure_rewrite to false if default setting is
true for this specific ddoc . Before opening a ticket I would lie to
discuss this option first here, but it may be really useful in near
future.
- benoit
[jira] Commented: (COUCHDB-884) Improve error handling in couch_rep_reader
[
https://issues.apache.org/jira/browse/COUCHDB-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908432#action_12908432
]
Filipe Manana commented on COUCHDB-884:
---
Forgot to mention before, that if open_doc_revs in rep_reader doesn't a return
a list where all members are #doc{} records (for e.g. {{not_found, missing},
couch_doc:parse_rev(Rev)}), the rep_writer will crash due to a badmatch
exception.
> Improve error handling in couch_rep_reader
> --
>
> Key: COUCHDB-884
> URL: https://issues.apache.org/jira/browse/COUCHDB-884
> Project: CouchDB
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 1.0.1
>Reporter: Filipe Manana
>Assignee: Filipe Manana
>Priority: Minor
> Attachments: rep_reader_errors.patch
>
>
> Currently, the replicator might crash when trying to read a doc from a remote
> DB. This is due unmatched clauses in a function. Example:
> ** Last message in was {'DOWN',#Ref<0.0.0.687>,process,<0.216.0>,
> {function_clause,
> [{couch_rep_reader,'-open_doc_revs/3-fun-1-',
>[{[{<<"error">>,<<"unauthorized">>},
> {<<"reason">>,<<"Authentication required.">>}]},
> The following patch avoids that the replicator crashes in this case and adds
> a useful error log message as well.
> Is anyone against applying this to trunk and 1.0.x? Adam?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908431#action_12908431 ] J Chris Anderson commented on COUCHDB-869: -- I just had a beautiful baby girl named Irma, so I don't plan to respond to mail, except occasionally if it's a fun one. If you have an urgent request, please CC he...@couch.io and we'll make sure someone reads it. Thanks, Chris PS. Please let me know if this responder is hitting mailing lists, that would be lame. -- Chris Anderson http://jchrisa.net -- couch.io > commonjs implementation creates circular references in the design document > -- > > Key: COUCHDB-869 > URL: https://issues.apache.org/jira/browse/COUCHDB-869 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Chris Anderson > Fix For: 1.0.2 > > Attachments: commonjs_circular_ref.diff > > > this prevents JSON.stringify(this) from working in show functions, as the > JSON.stringify function gets too much recursion. The culprit is the parent > references created by our CommonJS implementation. > test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson resolved COUCHDB-869. Resolution: Fixed fixed in r996266 and r996267 > commonjs implementation creates circular references in the design document > -- > > Key: COUCHDB-869 > URL: https://issues.apache.org/jira/browse/COUCHDB-869 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Reporter: Chris Anderson > Fix For: 1.0.2 > > Attachments: commonjs_circular_ref.diff > > > this prevents JSON.stringify(this) from working in show functions, as the > JSON.stringify function gets too much recursion. The culprit is the parent > references created by our CommonJS implementation. > test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
