date:20100706

On Wed, Jul 7, 2010 at 3:05 AM,   wrote:
> Author: jchris
> Date: Wed Jul  7 01:05:01 2010
> New Revision: 961052
>
> URL: http://svn.apache.org/viewvc?rev=961052&view=rev
> Log:
> avoid Futon popup when listing databases that cant be accessed
>
> Modified:
>    couchdb/trunk/share/www/script/futon.browse.js
>
> Modified: couchdb/trunk/share/www/script/futon.browse.js
> URL: 
> http://svn.apache.org/viewvc/couchdb/trunk/share/www/script/futon.browse.js?rev=961052&r1=961051&r2=961052&view=diff
> ==
> --- couchdb/trunk/share/www/script/futon.browse.js [utf-8] (original)
> +++ couchdb/trunk/share/www/script/futon.browse.js [utf-8] Wed Jul  7 
> 01:05:01 2010
> @@ -62,7 +62,8 @@
>                     
> .find("td.size").text($.futon.formatSize(info.disk_size)).end()
>                     .find("td.count").text(info.doc_count).end()
>                     .find("td.seq").text(info.update_seq);
> -                }
> +                },
> +                error : function() {}
>               });
>             });
>             $("#databases tbody tr:odd").addClass("odd");
>
>
>

I've done a patch that solve this differently in my replicator_db
branch. Instread of ignoring all errors it only ignore 401, also it
doesn't list these databases. What do you think about this diff ? :

diff --git a/share/www/script/futon.browse.js b/share/www/script/futon.browse.js
index 354a6a6..70632f9 100644
--- a/share/www/script/futon.browse.js
+++ b/share/www/script/futon.browse.js
@@ -51,17 +51,25 @@
 var dbsOnPage = dbs.slice(offset, offset + maxPerPage);

 $.each(dbsOnPage, function(idx, dbName) {
-  $("#databases tbody.content").append("" +
-"" +
-  dbName + "" +
-"" +
-"");
+
   $.couch.db(dbName).info({
 success: function(info) {
-  $("#databases tbody.content tr:eq(" + idx + ")")
-
.find("td.size").text($.futon.formatSize(info.disk_size)).end()
-.find("td.count").text(info.doc_count).end()
-.find("td.seq").text(info.update_seq);
+
+  var tr = $("" +
+dbName + "" +
+  "" +
+  "")
+
.find("td.size").text($.futon.formatSize(info.disk_size)).end()
+  .find("td.count").text(info.doc_count).end()
+  .find("td.seq").text(info.update_seq).end()
+
+  tr.appendTo("#databases tbody.content");
+
+},
+error: function(status, error, reason) {
+  if (status != 401) {
+alert("Error: " + error + "\n\n" + reason);
+  }
 }
   });
 });

Re: delayed_commits false

On Wed, Jul 7, 2010 at 3:56 AM, Robert Newson  wrote:
> I had started a page to capture the nuances of these settings at
> http://wiki.apache.org/couchdb/Durability_Matrix but never finished
> it. It's possible some of the prose could be reshaped into a concise
> summary of the difficult balancing act we're attempting here.
>
> For what it's worth, I'd prefer to keep this setting as-is for 1.0.
> Having several 'durability profiles' to choose from would be very
> neat, though, and displaying the current profile prominently in Futon
> should convey the message far better than docs or wiki. Consider how
> often the 'admin party' text gets people thinking about locking down
> their server...
>
> B.
>
I dislike to have too much options though.

@damien
I don't understand this "keep it for 1.0" mantra. Since it's more a
"philosophical" change than a technical one, I would prefer that
change on 1.0 whatever this number means. How do people  use CouchDB
in production ? Is delayed_commit turned off most of the time ?

About the use on laptop and co, laptops are likely less stable than
server machines, and we tend to shutdown them more often too. With
delayed_commit=True, when someone shutdown his laptop and forget to
apply delayed commit (and most of the time, if we don't automatize
that, I bet he will), data in memory will be lost.

 As a user of openbsd, one of the reasons I use this system (except
its simplicity) is that it is secured by default on the contrary most
linuxes/bsds aren't. Most of the openbsd users know that security will
impact performances. I think I would prefer to have a completly safe
couchdb even if performances decreased.

- benoit.

[jira] Updated: (COUCHDB-815) Non-standard HTTP methods for view handlers (AKA WebDAV is b0rken) [PATCH]

2010-07-06 Thread Jason Smith (JIRA)


 [ 
https://issues.apache.org/jira/browse/COUCHDB-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Smith updated COUCHDB-815:


Environment: Erlang/OTP R13B04

Note my erlang version since I am unsure if my patch (catch _:_) supports old 
OTP which for all I know throws single atoms instead of class:instance

> Non-standard HTTP methods for view handlers (AKA WebDAV is b0rken) [PATCH]
> --
>
> Key: COUCHDB-815
> URL: https://issues.apache.org/jira/browse/COUCHDB-815
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 1.0
> Environment: Erlang/OTP R13B04
>Reporter: Jason Smith
>Priority: Minor
> Attachments: allow_http_method_convert_to_binary.patch, 
> bad_allow_any_http_method.patch
>
>
> CouchDB prevents the new view server handler methods, _show, _update, etc. 
> from handling unknown HTTP methods. This prevents Couch apps from being able 
> to implement extensions to the HTTP specification or to add 
> application-specific methods to HTTP, violating the spirit of _show and 
> _update.
> For example, it is not possible to make a CouchApp WebDAV server because 
> _show and _list must support the PROPFIND method.
> In couch_httpd:handle_request_int/5, the response from Mochi is coerced to an 
> atom if and only if the atom already exists (using 
> couch_util:to_existing_atom/1). That is an odd whitelist, to say the least:
> $ curl localhost:5984 -X PROPFIND # Crashes mochiweb when 
> to_existing_atom throws badarg
> curl: (52) Empty reply from server
> $ curl localhost:5984 -X list_to_binary # Any atom works
> {"error":"method_not_allowed","reason":"Only GET,HEAD allowed"}
> Considering the cURL commands above, I filed this as a bug, not a feature. I 
> will explore some options and submit patches.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: delayed_commits false

2010-07-06 Thread Robert Newson

I had started a page to capture the nuances of these settings at
http://wiki.apache.org/couchdb/Durability_Matrix but never finished
it. It's possible some of the prose could be reshaped into a concise
summary of the difficult balancing act we're attempting here.

For what it's worth, I'd prefer to keep this setting as-is for 1.0.
Having several 'durability profiles' to choose from would be very
neat, though, and displaying the current profile prominently in Futon
should convey the message far better than docs or wiki. Consider how
often the 'admin party' text gets people thinking about locking down
their server...

B.

On Tue, Jul 6, 2010 at 9:18 PM, J Chris Anderson  wrote:
>>
>>>
>>> Maybe the thing to do is to put a note about this config item somewhere
>>> prominent in Futon. The Configuration page is obvious, but not prominent
>>> enough.
>>>
>
> I've got a nice little paragraph sitting on the config page in Futon (good 
> enough, I think)
>
> For the strongest consistency guarantees, delayed_commits should be 
> set to false. The default value of true is designed for 
> single-user performance. For more details see the CouchDB wiki on Delayed 
> Commits.
>
> The only issue is that there is no such wiki page (or at least I can't find 
> one.)
>
> Anyone care to summarize the full-commit tradeoff in a user-friendly way? If 
> you are up for doing that, but aren't up to editing the wiki, even just 
> replying to this thread with the language would be helpful, and then I can 
> put the page up and I'll add this documentation to trunk for 1.0
>
> Chris

Re: delayed_commits false

> 
>> 
>> Maybe the thing to do is to put a note about this config item somewhere
>> prominent in Futon. The Configuration page is obvious, but not prominent
>> enough.
>> 

I've got a nice little paragraph sitting on the config page in Futon (good 
enough, I think)

For the strongest consistency guarantees, delayed_commits should be 
set to false. The default value of true is designed for 
single-user performance. For more details see the CouchDB wiki on Delayed 
Commits.

The only issue is that there is no such wiki page (or at least I can't find 
one.)

Anyone care to summarize the full-commit tradeoff in a user-friendly way? If 
you are up for doing that, but aren't up to editing the wiki, even just 
replying to this thread with the language would be helpful, and then I can put 
the page up and I'll add this documentation to trunk for 1.0

Chris

[jira] Closed: (COUCHDB-819) rev 958039 breaks "Save Document"

2010-07-06 Thread Chris Anderson (JIRA)


 [ 
https://issues.apache.org/jira/browse/COUCHDB-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Anderson closed COUCHDB-819.
--

Resolution: Fixed

thanks, this was due to an incomplete backport, and it should be fixed now. Let 
us know if the problem is still there in the 0.11.x branch

> rev 958039 breaks "Save Document"
> -
>
> Key: COUCHDB-819
> URL: https://issues.apache.org/jira/browse/COUCHDB-819
> Project: CouchDB
>  Issue Type: Bug
>  Components: Futon
>Affects Versions: 0.11
> Environment: Ubuntu 10.04, amd64
>Reporter: Nome Consulting
>
> The following patch fixes a bug introduced by rev 958039. fullCommit is not 
> defined and because of it some browsers break at line 362. beforeSend is not 
> used in saveDoc.
> Index: share/www/script/jquery.couch.js   
>   
> 
> ===   
>   
> 
> --- share/www/script/jquery.couch.js(revision 961023) 
>   
> 
> +++ share/www/script/jquery.couch.js(working copy)
>   
> 
> @@ -359,7 +359,7 @@   
>   
> 
>  saveDoc: function(doc, options) {
>   
> 
>options = options || {};   
>   
> 
>var db = this; 
>   
> 
> -  var beforeSend = fullCommit(options);  
>   
> 
> +  //var beforeSend = fullCommit(options);
>   
> 
>if (doc._id === undefined) {   
>   
> 
>  var method = "POST"; 
>   
> 
>  var uri = this.uri;  
>   
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (COUCHDB-819) rev 958039 breaks "Save Document"

2010-07-06 Thread Nome Consulting (JIRA)

rev 958039 breaks "Save Document"
-

 Key: COUCHDB-819
 URL: https://issues.apache.org/jira/browse/COUCHDB-819
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 0.11
 Environment: Ubuntu 10.04, amd64
Reporter: Nome Consulting


The following patch fixes a bug introduced by rev 958039. fullCommit is not 
defined and because of it some browsers break at line 362. beforeSend is not 
used in saveDoc.

Index: share/www/script/jquery.couch.js 


=== 


--- share/www/script/jquery.couch.js(revision 961023)   


+++ share/www/script/jquery.couch.js(working copy)  


@@ -359,7 +359,7 @@ 


 saveDoc: function(doc, options) {  


   options = options || {}; 


   var db = this;   


-  var beforeSend = fullCommit(options);


+  //var beforeSend = fullCommit(options);  


   if (doc._id === undefined) { 


 var method = "POST";   


 var uri = this.uri;



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: delayed_commits false

>
> My general theory (extrapolating from my own behavior) is that no one reads
> documentation.
>

because there isn't any, zing! j/k

i actually agree with this for the most part but it doesn't mean that there
shouldn't be any for the people that use google to figure out things :)


>
> Maybe the thing to do is to put a note about this config item somewhere
> prominent in Futon. The Configuration page is obvious, but not prominent
> enough.
>

Or even better, Futon could have a drop down of different configurations for
"development", "single user", "multi user production" that set all the
config options to something pre-determined for that use case.


>
> I agree we shouldn't change the default right before 1.0, but it wouldn't
> be hard to slip a note or warning into Futon, with perhaps a link to a wiki
> page.
>
> Anyone have any brilliant ideas about the best place to put this note?
>
> Chris

Re: delayed_commits false

On Jul 6, 2010, at 4:13 PM, Robert Dionne wrote:

> Perhaps it's a matter of documentation. Most users aren't going to think 
> about the finer points of fsync and so forth, but will care about perceived 
> out of the box performance. 
> 
> However there will be scenarios where ACID will matter very much and good 
> documentation will help these users make the tradeoff. I think a key point is 
> that users who do care are not harmed by the defaults.
> 

My general theory (extrapolating from my own behavior) is that no one reads 
documentation.

Maybe the thing to do is to put a note about this config item somewhere 
prominent in Futon. The Configuration page is obvious, but not prominent enough.

I agree we shouldn't change the default right before 1.0, but it wouldn't be 
hard to slip a note or warning into Futon, with perhaps a link to a wiki page.

Anyone have any brilliant ideas about the best place to put this note?

Chris

Re: delayed_commits false

2010-07-06 Thread Robert Dionne

Perhaps it's a matter of documentation. Most users aren't going to think about 
the finer points of fsync and so forth, but will care about perceived out of 
the box performance. 

However there will be scenarios where ACID will matter very much and good 
documentation will help these users make the tradeoff. I think a key point is 
that users who do care are not harmed by the defaults.
 




On Jul 6, 2010, at 6:58 PM, Volker Mische wrote:

> I have to admit that the point, that the main audience of a tarball are 
> developers is a good one. Perhaps people that do binary distributions of 
> CouchDB (like all the linux distros) could be encouraged to turn it to false 
> (though I have no idea what their general policy about changing defaults is).
> 
> Cheers,
>  Volker
> 
> On 07.07.2010 00:52, Mikeal Rogers wrote:
>> I think there is a balance that we can find here between user experience and
>> durability.
>> 
>> I think the biggest question for me is, who is the primary target of the
>> tarball download?
>> 
>> If it's developers, I think we should leave it on.
>> 
>> If it's people who are going to put it up, vanilla, in to production, we
>> should turn them off.
>> 
>> I know that I would certainly advocate keeping them off in the CouchDBX
>> build.
>> 
>> -Mikeal
>> 
>> On Tue, Jul 6, 2010 at 3:46 PM, Volker Mischewrote:
>> 
>>> On 07.07.2010 00:06, Damien Katz wrote:
>>> 
 
 On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:
 
  Hi All,
> 
> delayed_commits were enabled to have better performance especially for
> single writers. The price you pay for is that you potentially lose up to 
> one
> second of writes in case of a crash.
> 
> Such a setting makes sense, though in my opinion it shouldn't be enabled
> by default. I expect* that people running into performance issues at least
> take a look at the README or a FAQ section somewhere. There the
> delayed_commit setting could be pointed out.
> 
> I'd like to be able to say that on a vanilla CouchDB it's hard to lose
> data, but I can't atm. I'm also well aware that there will be plenty of
> performance tests when 1.0 is released and people will complain (if
> delayed_commits would be set to false by default) that it is horrible 
> slow.
> Though safety of the data is more important for me.
> 
> If the only reason why delayed_commits is true by default are the
> performance tests of some noobs, I really don't think it's a price worth
> paying.
> 
> *I know that in reality people don't
> 
> I would like to see delayed_commits=false for 1.0
> 
 
 Last year we turned off delayed commits by default. We got lots of
 complaints, the performance impact was too great. So we switched it back. 
 We
 aren't the first storage engine to go around on this. For example, Apple's
 core data switched to using full fsyncs for each write in 10.4, but then
 switched it back for 10.5:
 
 
 http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html
 
 "Important: The default behaviors in Mac OS X v10.4 an 10.5 are different.
 In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X v10.5 it
 does not."
 
 Anyway, we can improve the documentation warning's, etc, but we should
 stay with the current defaults.
 
 -Damien
 
 
>>> As 1.0 is approaching fast, I think this discussion is pretty important.
>>> Especially this thread showed that there are people that prefer setting
>>> delayed_commits to false. Although sometimes someone has to make the last
>>> call, and there is probably no one better than the creator of the project, I
>>> think it this case the decision should be made by more people.
>>> 
>>> For *me personally* the authority of Apache CouchDB are the committers. I
>>> would love to see them vote on this topic (being it public or private
>>> doesn't matter).
>>> 
>>> Cheers,
>>>  Volker
>>> 
>> 
>

Re: delayed_commits false

+1 on delaying a decision on this until after 1.0, it's a big change and if
we do make it we should let it sit in trunk and steep for a while.

But, JIRA is a terrible place to have a discussion so I'd rather we continue
to use the mailing list.

-Mikeal

On Tue, Jul 6, 2010 at 4:03 PM, Damien Katz  wrote:

> This issue has been discussed already. A change this big right before a 1.0
> release is a very bad idea. If we decided to change it, we'd need to wait a
> good amount of time to understand how it affects downstream projects that
> take the defaults.
>
> Here is a bug report that talks about it. There is more discussion in the
> mailing list as well.
>
> https://issues.apache.org/jira/browse/COUCHDB-449
>
> -Damien
>
>
> On Jul 6, 2010, at 3:58 PM, Volker Mische wrote:
>
> > I have to admit that the point, that the main audience of a tarball are
> developers is a good one. Perhaps people that do binary distributions of
> CouchDB (like all the linux distros) could be encouraged to turn it to false
> (though I have no idea what their general policy about changing defaults
> is).
> >
> > Cheers,
> >  Volker
> >
> > On 07.07.2010 00:52, Mikeal Rogers wrote:
> >> I think there is a balance that we can find here between user experience
> and
> >> durability.
> >>
> >> I think the biggest question for me is, who is the primary target of the
> >> tarball download?
> >>
> >> If it's developers, I think we should leave it on.
> >>
> >> If it's people who are going to put it up, vanilla, in to production, we
> >> should turn them off.
> >>
> >> I know that I would certainly advocate keeping them off in the CouchDBX
> >> build.
> >>
> >> -Mikeal
> >>
> >> On Tue, Jul 6, 2010 at 3:46 PM, Volker Mische >wrote:
> >>
> >>> On 07.07.2010 00:06, Damien Katz wrote:
> >>>
> 
>  On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:
> 
>   Hi All,
> >
> > delayed_commits were enabled to have better performance especially
> for
> > single writers. The price you pay for is that you potentially lose up
> to one
> > second of writes in case of a crash.
> >
> > Such a setting makes sense, though in my opinion it shouldn't be
> enabled
> > by default. I expect* that people running into performance issues at
> least
> > take a look at the README or a FAQ section somewhere. There the
> > delayed_commit setting could be pointed out.
> >
> > I'd like to be able to say that on a vanilla CouchDB it's hard to
> lose
> > data, but I can't atm. I'm also well aware that there will be plenty
> of
> > performance tests when 1.0 is released and people will complain (if
> > delayed_commits would be set to false by default) that it is horrible
> slow.
> > Though safety of the data is more important for me.
> >
> > If the only reason why delayed_commits is true by default are the
> > performance tests of some noobs, I really don't think it's a price
> worth
> > paying.
> >
> > *I know that in reality people don't
> >
> > I would like to see delayed_commits=false for 1.0
> >
> 
>  Last year we turned off delayed commits by default. We got lots of
>  complaints, the performance impact was too great. So we switched it
> back. We
>  aren't the first storage engine to go around on this. For example,
> Apple's
>  core data switched to using full fsyncs for each write in 10.4, but
> then
>  switched it back for 10.5:
> 
> 
> 
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html
> 
>  "Important: The default behaviors in Mac OS X v10.4 an 10.5 are
> different.
>  In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X
> v10.5 it
>  does not."
> 
>  Anyway, we can improve the documentation warning's, etc, but we should
>  stay with the current defaults.
> 
>  -Damien
> 
> 
> >>> As 1.0 is approaching fast, I think this discussion is pretty
> important.
> >>> Especially this thread showed that there are people that prefer setting
> >>> delayed_commits to false. Although sometimes someone has to make the
> last
> >>> call, and there is probably no one better than the creator of the
> project, I
> >>> think it this case the decision should be made by more people.
> >>>
> >>> For *me personally* the authority of Apache CouchDB are the committers.
> I
> >>> would love to see them vote on this topic (being it public or private
> >>> doesn't matter).
> >>>
> >>> Cheers,
> >>>  Volker
> >>>
> >>
> >
>
>

Re: delayed_commits false

The difference when you do a couchapp push with delayed-commits on and off
drastically increases when you have a lot of binary attachments.

In some of my apps it's the difference between sub-second and 20 seconds.

-Mikeal

On Tue, Jul 6, 2010 at 4:01 PM, Volker Mische wrote:

> (memo to myself, don't send mails late at night)
>
> On the other hand, do developers care about performance? And if, they would
> read the documentation.
>
> Cheers,
>  Volker
>
>
> On 07.07.2010 00:58, Volker Mische wrote:
>
>> I have to admit that the point, that the main audience of a tarball are
>> developers is a good one. Perhaps people that do binary distributions of
>> CouchDB (like all the linux distros) could be encouraged to turn it to
>> false (though I have no idea what their general policy about changing
>> defaults is).
>>
>> Cheers,
>> Volker
>>
>> On 07.07.2010 00:52, Mikeal Rogers wrote:
>>
>>> I think there is a balance that we can find here between user
>>> experience and
>>> durability.
>>>
>>> I think the biggest question for me is, who is the primary target of the
>>> tarball download?
>>>
>>> If it's developers, I think we should leave it on.
>>>
>>> If it's people who are going to put it up, vanilla, in to production, we
>>> should turn them off.
>>>
>>> I know that I would certainly advocate keeping them off in the CouchDBX
>>> build.
>>>
>>> -Mikeal
>>>
>>> On Tue, Jul 6, 2010 at 3:46 PM, Volker
>>> Mischewrote:
>>>
>>>  On 07.07.2010 00:06, Damien Katz wrote:


> On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:
>
> Hi All,
>
>>
>> delayed_commits were enabled to have better performance especially for
>> single writers. The price you pay for is that you potentially lose
>> up to one
>> second of writes in case of a crash.
>>
>> Such a setting makes sense, though in my opinion it shouldn't be
>> enabled
>> by default. I expect* that people running into performance issues
>> at least
>> take a look at the README or a FAQ section somewhere. There the
>> delayed_commit setting could be pointed out.
>>
>> I'd like to be able to say that on a vanilla CouchDB it's hard to lose
>> data, but I can't atm. I'm also well aware that there will be
>> plenty of
>> performance tests when 1.0 is released and people will complain (if
>> delayed_commits would be set to false by default) that it is
>> horrible slow.
>> Though safety of the data is more important for me.
>>
>> If the only reason why delayed_commits is true by default are the
>> performance tests of some noobs, I really don't think it's a price
>> worth
>> paying.
>>
>> *I know that in reality people don't
>>
>> I would like to see delayed_commits=false for 1.0
>>
>>
> Last year we turned off delayed commits by default. We got lots of
> complaints, the performance impact was too great. So we switched it
> back. We
> aren't the first storage engine to go around on this. For example,
> Apple's
> core data switched to using full fsyncs for each write in 10.4, but
> then
> switched it back for 10.5:
>
>
>
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html
>
>
> "Important: The default behaviors in Mac OS X v10.4 an 10.5 are
> different.
> In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X
> v10.5 it
> does not."
>
> Anyway, we can improve the documentation warning's, etc, but we should
> stay with the current defaults.
>
> -Damien
>
>
>  As 1.0 is approaching fast, I think this discussion is pretty
 important.
 Especially this thread showed that there are people that prefer setting
 delayed_commits to false. Although sometimes someone has to make the
 last
 call, and there is probably no one better than the creator of the
 project, I
 think it this case the decision should be made by more people.

 For *me personally* the authority of Apache CouchDB are the
 committers. I
 would love to see them vote on this topic (being it public or private
 doesn't matter).

 Cheers,
 Volker


>>>
>>
>

Re: delayed_commits false

2010-07-06 Thread Damien Katz

This issue has been discussed already. A change this big right before a 1.0 
release is a very bad idea. If we decided to change it, we'd need to wait a 
good amount of time to understand how it affects downstream projects that take 
the defaults.

Here is a bug report that talks about it. There is more discussion in the 
mailing list as well.

https://issues.apache.org/jira/browse/COUCHDB-449

-Damien


On Jul 6, 2010, at 3:58 PM, Volker Mische wrote:

> I have to admit that the point, that the main audience of a tarball are 
> developers is a good one. Perhaps people that do binary distributions of 
> CouchDB (like all the linux distros) could be encouraged to turn it to false 
> (though I have no idea what their general policy about changing defaults is).
> 
> Cheers,
>  Volker
> 
> On 07.07.2010 00:52, Mikeal Rogers wrote:
>> I think there is a balance that we can find here between user experience and
>> durability.
>> 
>> I think the biggest question for me is, who is the primary target of the
>> tarball download?
>> 
>> If it's developers, I think we should leave it on.
>> 
>> If it's people who are going to put it up, vanilla, in to production, we
>> should turn them off.
>> 
>> I know that I would certainly advocate keeping them off in the CouchDBX
>> build.
>> 
>> -Mikeal
>> 
>> On Tue, Jul 6, 2010 at 3:46 PM, Volker Mischewrote:
>> 
>>> On 07.07.2010 00:06, Damien Katz wrote:
>>> 
 
 On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:
 
  Hi All,
> 
> delayed_commits were enabled to have better performance especially for
> single writers. The price you pay for is that you potentially lose up to 
> one
> second of writes in case of a crash.
> 
> Such a setting makes sense, though in my opinion it shouldn't be enabled
> by default. I expect* that people running into performance issues at least
> take a look at the README or a FAQ section somewhere. There the
> delayed_commit setting could be pointed out.
> 
> I'd like to be able to say that on a vanilla CouchDB it's hard to lose
> data, but I can't atm. I'm also well aware that there will be plenty of
> performance tests when 1.0 is released and people will complain (if
> delayed_commits would be set to false by default) that it is horrible 
> slow.
> Though safety of the data is more important for me.
> 
> If the only reason why delayed_commits is true by default are the
> performance tests of some noobs, I really don't think it's a price worth
> paying.
> 
> *I know that in reality people don't
> 
> I would like to see delayed_commits=false for 1.0
> 
 
 Last year we turned off delayed commits by default. We got lots of
 complaints, the performance impact was too great. So we switched it back. 
 We
 aren't the first storage engine to go around on this. For example, Apple's
 core data switched to using full fsyncs for each write in 10.4, but then
 switched it back for 10.5:
 
 
 http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html
 
 "Important: The default behaviors in Mac OS X v10.4 an 10.5 are different.
 In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X v10.5 it
 does not."
 
 Anyway, we can improve the documentation warning's, etc, but we should
 stay with the current defaults.
 
 -Damien
 
 
>>> As 1.0 is approaching fast, I think this discussion is pretty important.
>>> Especially this thread showed that there are people that prefer setting
>>> delayed_commits to false. Although sometimes someone has to make the last
>>> call, and there is probably no one better than the creator of the project, I
>>> think it this case the decision should be made by more people.
>>> 
>>> For *me personally* the authority of Apache CouchDB are the committers. I
>>> would love to see them vote on this topic (being it public or private
>>> doesn't matter).
>>> 
>>> Cheers,
>>>  Volker
>>> 
>> 
>

Re: delayed_commits false

2010-07-06 Thread Volker Mische

(memo to myself, don't send mails late at night)

On the other hand, do developers care about performance? And if, they
would read the documentation.

Cheers,
Volker

On 07.07.2010 00:58, Volker Mische wrote:

I have to admit that the point, that the main audience of a tarball are
developers is a good one. Perhaps people that do binary distributions of
CouchDB (like all the linux distros) could be encouraged to turn it to
false (though I have no idea what their general policy about changing
defaults is).

Cheers,
Volker

On 07.07.2010 00:52, Mikeal Rogers wrote:

I think there is a balance that we can find here between user
experience and
durability.

I think the biggest question for me is, who is the primary target of the
tarball download?

If it's developers, I think we should leave it on.

If it's people who are going to put it up, vanilla, in to production, we
should turn them off.

I know that I would certainly advocate keeping them off in the CouchDBX
build.

-Mikeal

On Tue, Jul 6, 2010 at 3:46 PM, Volker
Mischewrote:

On 07.07.2010 00:06, Damien Katz wrote:

On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:

Hi All,

delayed_commits were enabled to have better performance especially for
single writers. The price you pay for is that you potentially lose
up to one
second of writes in case of a crash.

Such a setting makes sense, though in my opinion it shouldn't be
enabled
by default. I expect* that people running into performance issues
at least
take a look at the README or a FAQ section somewhere. There the
delayed_commit setting could be pointed out.

I'd like to be able to say that on a vanilla CouchDB it's hard to lose
data, but I can't atm. I'm also well aware that there will be
plenty of
performance tests when 1.0 is released and people will complain (if
delayed_commits would be set to false by default) that it is
horrible slow.
Though safety of the data is more important for me.

If the only reason why delayed_commits is true by default are the
performance tests of some noobs, I really don't think it's a price
worth
paying.

*I know that in reality people don't

I would like to see delayed_commits=false for 1.0

Last year we turned off delayed commits by default. We got lots of
complaints, the performance impact was too great. So we switched it
back. We
aren't the first storage engine to go around on this. For example,
Apple's
core data switched to using full fsyncs for each write in 10.4, but
then
switched it back for 10.5:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html

"Important: The default behaviors in Mac OS X v10.4 an 10.5 are
different.
In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X
v10.5 it
does not."

Anyway, we can improve the documentation warning's, etc, but we should
stay with the current defaults.

-Damien

As 1.0 is approaching fast, I think this discussion is pretty important.
Especially this thread showed that there are people that prefer setting
delayed_commits to false. Although sometimes someone has to make the
last
call, and there is probably no one better than the creator of the
project, I
think it this case the decision should be made by more people.

For *me personally* the authority of Apache CouchDB are the
committers. I
would love to see them vote on this topic (being it public or private
doesn't matter).

Cheers,
Volker

Re: delayed_commits false

2010-07-06 Thread Volker Mische

I have to admit that the point, that the main audience of a tarball are
developers is a good one. Perhaps people that do binary distributions
of CouchDB (like all the linux distros) could be encouraged to turn it
to false (though I have no idea what their general policy about changing
defaults is).

Cheers,
Volker

On 07.07.2010 00:52, Mikeal Rogers wrote:

I think there is a balance that we can find here between user experience and
durability.

I think the biggest question for me is, who is the primary target of the
tarball download?

If it's developers, I think we should leave it on.

If it's people who are going to put it up, vanilla, in to production, we
should turn them off.

I know that I would certainly advocate keeping them off in the CouchDBX
build.

-Mikeal

On Tue, Jul 6, 2010 at 3:46 PM, Volker Mischewrote:

On 07.07.2010 00:06, Damien Katz wrote:

On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:

Hi All,

delayed_commits were enabled to have better performance especially for
single writers. The price you pay for is that you potentially lose up to one
second of writes in case of a crash.

Such a setting makes sense, though in my opinion it shouldn't be enabled
by default. I expect* that people running into performance issues at least
take a look at the README or a FAQ section somewhere. There the
delayed_commit setting could be pointed out.

I'd like to be able to say that on a vanilla CouchDB it's hard to lose
data, but I can't atm. I'm also well aware that there will be plenty of
performance tests when 1.0 is released and people will complain (if
delayed_commits would be set to false by default) that it is horrible slow.
Though safety of the data is more important for me.

If the only reason why delayed_commits is true by default are the
performance tests of some noobs, I really don't think it's a price worth
paying.

*I know that in reality people don't

I would like to see delayed_commits=false for 1.0

Last year we turned off delayed commits by default. We got lots of
complaints, the performance impact was too great. So we switched it back. We
aren't the first storage engine to go around on this. For example, Apple's
core data switched to using full fsyncs for each write in 10.4, but then
switched it back for 10.5:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html

"Important: The default behaviors in Mac OS X v10.4 an 10.5 are different.
In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X v10.5 it
does not."

Anyway, we can improve the documentation warning's, etc, but we should
stay with the current defaults.

-Damien

As 1.0 is approaching fast, I think this discussion is pretty important.
Especially this thread showed that there are people that prefer setting
delayed_commits to false. Although sometimes someone has to make the last
call, and there is probably no one better than the creator of the project, I
think it this case the decision should be made by more people.

For *me personally* the authority of Apache CouchDB are the committers. I
would love to see them vote on this topic (being it public or private
doesn't matter).

Cheers,
Volker

Re: delayed_commits false

I think there is a balance that we can find here between user experience and
durability.

I think the biggest question for me is, who is the primary target of the
tarball download?

If it's developers, I think we should leave it on.

If it's people who are going to put it up, vanilla, in to production, we
should turn them off.

I know that I would certainly advocate keeping them off in the CouchDBX
build.

-Mikeal

On Tue, Jul 6, 2010 at 3:46 PM, Volker Mische wrote:

> On 07.07.2010 00:06, Damien Katz wrote:
>
>>
>> On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:
>>
>>  Hi All,
>>>
>>> delayed_commits were enabled to have better performance especially for
>>> single writers. The price you pay for is that you potentially lose up to one
>>> second of writes in case of a crash.
>>>
>>> Such a setting makes sense, though in my opinion it shouldn't be enabled
>>> by default. I expect* that people running into performance issues at least
>>> take a look at the README or a FAQ section somewhere. There the
>>> delayed_commit setting could be pointed out.
>>>
>>> I'd like to be able to say that on a vanilla CouchDB it's hard to lose
>>> data, but I can't atm. I'm also well aware that there will be plenty of
>>> performance tests when 1.0 is released and people will complain (if
>>> delayed_commits would be set to false by default) that it is horrible slow.
>>> Though safety of the data is more important for me.
>>>
>>> If the only reason why delayed_commits is true by default are the
>>> performance tests of some noobs, I really don't think it's a price worth
>>> paying.
>>>
>>> *I know that in reality people don't
>>>
>>> I would like to see delayed_commits=false for 1.0
>>>
>>
>> Last year we turned off delayed commits by default. We got lots of
>> complaints, the performance impact was too great. So we switched it back. We
>> aren't the first storage engine to go around on this. For example, Apple's
>> core data switched to using full fsyncs for each write in 10.4, but then
>> switched it back for 10.5:
>>
>>
>> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html
>>
>> "Important: The default behaviors in Mac OS X v10.4 an 10.5 are different.
>> In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X v10.5 it
>> does not."
>>
>> Anyway, we can improve the documentation warning's, etc, but we should
>> stay with the current defaults.
>>
>> -Damien
>>
>>
> As 1.0 is approaching fast, I think this discussion is pretty important.
> Especially this thread showed that there are people that prefer setting
> delayed_commits to false. Although sometimes someone has to make the last
> call, and there is probably no one better than the creator of the project, I
> think it this case the decision should be made by more people.
>
> For *me personally* the authority of Apache CouchDB are the committers. I
> would love to see them vote on this topic (being it public or private
> doesn't matter).
>
> Cheers,
>  Volker
>

Re: delayed_commits false

2010-07-06 Thread Volker Mische

On 07.07.2010 00:06, Damien Katz wrote:

On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:

Hi All,

delayed_commits were enabled to have better performance especially for single
writers. The price you pay for is that you potentially lose up to one second of
writes in case of a crash.

Such a setting makes sense, though in my opinion it shouldn't be enabled by
default. I expect* that people running into performance issues at least take a
look at the README or a FAQ section somewhere. There the delayed_commit setting
could be pointed out.

I'd like to be able to say that on a vanilla CouchDB it's hard to lose data,
but I can't atm. I'm also well aware that there will be plenty of performance
tests when 1.0 is released and people will complain (if delayed_commits would
be set to false by default) that it is horrible slow. Though safety of the data
is more important for me.

If the only reason why delayed_commits is true by default are the performance
tests of some noobs, I really don't think it's a price worth paying.

*I know that in reality people don't

I would like to see delayed_commits=false for 1.0

Last year we turned off delayed commits by default. We got lots of complaints,
the performance impact was too great. So we switched it back. We aren't the
first storage engine to go around on this. For example, Apple's core data
switched to using full fsyncs for each write in 10.4, but then switched it back
for 10.5:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html

"Important: The default behaviors in Mac OS X v10.4 an 10.5 are different. In Mac OS
X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X v10.5 it does not."

Anyway, we can improve the documentation warning's, etc, but we should stay
with the current defaults.

-Damien

As 1.0 is approaching fast, I think this discussion is pretty important.
Especially this thread showed that there are people that prefer setting
delayed_commits to false. Although sometimes someone has to make the
last call, and there is probably no one better than the creator of the
project, I think it this case the decision should be made by more people.

For *me personally* the authority of Apache CouchDB are the committers.
I would love to see them vote on this topic (being it public or private
doesn't matter).

Cheers,
Volker

Re: [jira] Updated: (COUCHDB-776) _replicator DB

full diff :

http://github.com/benoitc/couchdb/compare/ba95749f2912f972a22ca92441c02b886341285a..._replicator_db

- benoit

On Wed, Jul 7, 2010 at 12:15 AM, Benoit Chesneau (JIRA)  wrote:
>
>     [ 
> https://issues.apache.org/jira/browse/COUCHDB-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
>
> Benoit Chesneau updated COUCHDB-776:
> 
>
>    Attachment: replicator admin.jpg
>
> I updated fdmanana patch by ading new replicator ui in futon. Other changes 
> are :
>
> _ new replicator ui in futon : allows creation of new replication tasks, list 
>  of completed, triggered or error tasks and deletion of a task
>
> - secure _replicator ui : only _admin and _replicator roles can read the db. 
> So none can't see credentials used for replication (which are save in the 
> doc).  None admin or _replicator roles can still start replicate by posting 
> to _replicate (which have been changed). Check attached screenshot
>
> - new _replicate function
>
> Code is available here :
>
> http://github.com/benoitc/couchdb/tree/_replicator_db
>
>> _replicator DB
>> --
>>
>>                 Key: COUCHDB-776
>>                 URL: https://issues.apache.org/jira/browse/COUCHDB-776
>>             Project: CouchDB
>>          Issue Type: New Feature
>>          Components: Replication
>>         Environment: trunk
>>            Reporter: Filipe Manana
>>            Assignee: Filipe Manana
>>         Attachments: replicator admin.jpg
>>
>>
>> As discussed in the mailing list thread "_replicator DB" (May) -
>> http://mail-archives.apache.org/mod_mbox/couchdb-dev/201005.mbox/%3caanlktilfnng9fuxuxjb5cazo6__mjaogpiw4xtuzp...@mail.gmail.com%3e
>> The patch follows.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

[jira] Updated: (COUCHDB-776) _replicator DB

2010-07-06 Thread Benoit Chesneau (JIRA)


 [ 
https://issues.apache.org/jira/browse/COUCHDB-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benoit Chesneau updated COUCHDB-776:


Attachment: replicator admin.jpg

I updated fdmanana patch by ading new replicator ui in futon. Other changes are 
:

_ new replicator ui in futon : allows creation of new replication tasks, list  
of completed, triggered or error tasks and deletion of a task

- secure _replicator ui : only _admin and _replicator roles can read the db. So 
none can't see credentials used for replication (which are save in the doc).  
None admin or _replicator roles can still start replicate by posting to 
_replicate (which have been changed). Check attached screenshot

- new _replicate function

Code is available here : 

http://github.com/benoitc/couchdb/tree/_replicator_db

> _replicator DB
> --
>
> Key: COUCHDB-776
> URL: https://issues.apache.org/jira/browse/COUCHDB-776
> Project: CouchDB
>  Issue Type: New Feature
>  Components: Replication
> Environment: trunk
>Reporter: Filipe Manana
>Assignee: Filipe Manana
> Attachments: replicator admin.jpg
>
>
> As discussed in the mailing list thread "_replicator DB" (May) -
> http://mail-archives.apache.org/mod_mbox/couchdb-dev/201005.mbox/%3caanlktilfnng9fuxuxjb5cazo6__mjaogpiw4xtuzp...@mail.gmail.com%3e
> The patch follows.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: delayed_commits false

2010-07-06 Thread Damien Katz

On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:

> Hi All,
> 
> delayed_commits were enabled to have better performance especially for single 
> writers. The price you pay for is that you potentially lose up to one second 
> of writes in case of a crash.
> 
> Such a setting makes sense, though in my opinion it shouldn't be enabled by 
> default. I expect* that people running into performance issues at least take 
> a look at the README or a FAQ section somewhere. There the delayed_commit 
> setting could be pointed out.
> 
> I'd like to be able to say that on a vanilla CouchDB it's hard to lose data, 
> but I can't atm. I'm also well aware that there will be plenty of performance 
> tests when 1.0 is released and people will complain (if delayed_commits would 
> be set to false by default) that it is horrible slow. Though safety of the 
> data is more important for me.
> 
> If the only reason why delayed_commits is true by default are the performance 
> tests of some noobs, I really don't think it's a price worth paying.
> 
> *I know that in reality people don't
> 
> I would like to see delayed_commits=false for 1.0

Last year we turned off delayed commits by default. We got lots of complaints, 
the performance impact was too great. So we switched it back. We aren't the 
first storage engine to go around on this. For example, Apple's core data 
switched to using full fsyncs for each write in 10.4, but then switched it back 
for 10.5:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html

"Important: The default behaviors in Mac OS X v10.4 an 10.5 are different. In 
Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X v10.5 it does 
not."

Anyway, we can improve the documentation warning's, etc, but we should stay 
with the current defaults.

-Damien

> 
> Cheers,
>  Volker

Re: delayed_commits false

2010-07-06 Thread Klaus Trainer

---[Sorry for the noise and not properly quoting previously]---

Mikeal, I suspect you mixed up local data consistency and durability...

In fact, I think it's only the durability one of the ACID properties
that's affected. Basically, the only difference that
delayed_commits=true makes is that if there is e.g. a power outage, the
result of write operations that have committed in the last three or so
seconds might be lost.

I know, it's no question that local data consistency and the other
consistency property you refer to as runtime consistency are not
affected by the delayed_commits setting.

Cheers,
Klaus

On Tue, 2010-07-06 at 13:28 -0700, Mikeal Rogers wrote:
> Just for reference, most SQL databases ship with the fsync to their
> log on a
> 1s or longer cycle, it's pretty standard.
> 
> delayed-commits on doesn't reduce durability because the writes to log
> are
> still append-only and can survive invalid writes and crashes and all
> that.
> Also, they don't reduce runtime consistency because the response isn't
> returned until the document is available. All they do is give the
> client a
> *different* consistency guarantee (available rather than persisted to
> disc).

Re: delayed_commits false

2010-07-06 Thread Klaus Trainer

Mikeal, I suspect you mixed up local data consistency and durability...

In fact, I think it's only the durability one of the ACID properties
that's affected. Basically, the only difference that
delayed_commits=true makes is that if there is e.g. a power outage, the
result of write operations that have committed in the last three or so
seconds might be lost.

I know, it's no question that local data consistency and the other
consistency property you refer to as runtime consistency are not
affected by the delayed_commits setting.

Cheers,
Klaus


> still append-only and can survive invalid writes and crashes and all
> that.
> Also, they don't reduce runtime consistency because the response isn't
> returned until the document is available. All they do is give the
> client a
> *different* consistency guarantee (available rather than persisted to
> disc).

Re: delayed_commits false

The difference between delayed-commits on and off is not the biggest
difference in consistency and durability between mongo and couch.

MongoDB doesn't return a response by default on a write. You just write to
the socket and hope that it's available.

MongoDB lets the kernel decide to flush to disc whenever. Newer version
force an fsync every minute.

MongoDB writes to their file format "in place" and don't keep *anything*
append-only around which is why they suffer from these kinds of long term
corruption bugs where data can't be recovered.

These things don't just set MongoDB apart from CouchDB in terms of
consistency and durability they set them apart from all other modern
databases. Even Redis has more consistency and durability than this.

-Mikeal

On Tue, Jul 6, 2010 at 1:22 PM, Zachary Zolton wrote:

> To Klaus's point, we have to choose our FUD:
> "CouchDB is sooo slow" or "CouchDB will lose your data"
>
> Would the latter cause more harm than the former? I don't know, but
> Google already includes the phrase "mongodb losing data" in its search
> suggestions.
>
> I'd hate for CouchDB to end up in the same boat.
>
> On Tue, Jul 6, 2010 at 3:07 PM, Klaus Trainer 
> wrote:
> > Just to put my two cents in...
> >
> > It's a matter of to be or not to be (ACID (by default)).
> >
> > With delayed_commits=true, data operations aren't durable anymore.
> > Consequently, if it's the default setting, some people might say that
> > CouchDB does not meet ACID requirements. People mostly tend to simplify.
> > We will hardly be able to eliminate (sometimes vicious) superficiality,
> > but we rather should face the fact that such partially true assertions
> > may be harmful.
> >
> > Take MySQL as an example: there are (still) people stating that MySQL is
> > not ACID compliant and doesn't support transactions. They are partially
> > right with that: it's true for the default storage engine (MyISAM), but
> > definitely not for InnoDB.
> >
> > With choosing stronger guarantees by default--as long as it goes in line
> > with basic design decisions--we just eliminate any room for such
> > confusion (or maybe even FUD that is spread by competitors). Basically,
> > when comparing with other databases, that's way more important than a
> > higher rank in an inadequate performance benchmark (pissing contest).
> >
> > - Klaus
> >
> >
> > On Tue, 2010-07-06 at 16:43 +0200, Benoit Chesneau wrote:
> >> I would prefer to put delayed_commits=false too, to keep the promise
> >> we give to our users. We can't say on one side we are better than
> >> mongo for this while a simple power failure may result in lost of data
> >> by default (even if we are better since dbs won't be corrupted).
> >>
> >> The default should be the strongest imo. Like every os should be
> >> secure by default, we should  let the user know, we do the best *by
> >> default* to make sure data are safe on the disk. While they still have
> >> the possibility to bypass this "security" . But in this case, this is
> >> a choice.
> >>
> >> For those who worry about the marketing, this is also a good point of
> >> differentiation compared to others dbs. (/me remove his marketing hat)
> >> .
> >>
> >> - benoit
> >
> >
> >
>

Re: delayed_commits false

Just for reference, most SQL databases ship with the fsync to their log on a
1s or longer cycle, it's pretty standard.

delayed-commits on doesn't reduce durability because the writes to log are
still append-only and can survive invalid writes and crashes and all that.
Also, they don't reduce runtime consistency because the response isn't
returned until the document is available. All they do is give the client a
*different* consistency guarantee (available rather than persisted to disc).

Personally, i think it's better to default the guarantee to persisted but I
can see why it's advantageous for some configurations to opt for the other.
The real question here is what guarantee we want to ship with by default,
one that optimizes single writer performance or one that offers a better
guarantee and is still performant under concurrent load.

-Mikeal

On Tue, Jul 6, 2010 at 1:07 PM, Klaus Trainer  wrote:

> Just to put my two cents in...
>
> It's a matter of to be or not to be (ACID (by default)).
>
> With delayed_commits=true, data operations aren't durable anymore.
> Consequently, if it's the default setting, some people might say that
> CouchDB does not meet ACID requirements. People mostly tend to simplify.
> We will hardly be able to eliminate (sometimes vicious) superficiality,
> but we rather should face the fact that such partially true assertions
> may be harmful.
>
> Take MySQL as an example: there are (still) people stating that MySQL is
> not ACID compliant and doesn't support transactions. They are partially
> right with that: it's true for the default storage engine (MyISAM), but
> definitely not for InnoDB.
>
> With choosing stronger guarantees by default--as long as it goes in line
> with basic design decisions--we just eliminate any room for such
> confusion (or maybe even FUD that is spread by competitors). Basically,
> when comparing with other databases, that's way more important than a
> higher rank in an inadequate performance benchmark (pissing contest).
>
> - Klaus
>
>
> On Tue, 2010-07-06 at 16:43 +0200, Benoit Chesneau wrote:
> > I would prefer to put delayed_commits=false too, to keep the promise
> > we give to our users. We can't say on one side we are better than
> > mongo for this while a simple power failure may result in lost of data
> > by default (even if we are better since dbs won't be corrupted).
> >
> > The default should be the strongest imo. Like every os should be
> > secure by default, we should  let the user know, we do the best *by
> > default* to make sure data are safe on the disk. While they still have
> > the possibility to bypass this "security" . But in this case, this is
> > a choice.
> >
> > For those who worry about the marketing, this is also a good point of
> > differentiation compared to others dbs. (/me remove his marketing hat)
> > .
> >
> > - benoit
>
>
>

Re: delayed_commits false

2010-07-06 Thread Zachary Zolton

To Klaus's point, we have to choose our FUD:
"CouchDB is sooo slow" or "CouchDB will lose your data"

Would the latter cause more harm than the former? I don't know, but
Google already includes the phrase "mongodb losing data" in its search
suggestions.

I'd hate for CouchDB to end up in the same boat.

On Tue, Jul 6, 2010 at 3:07 PM, Klaus Trainer  wrote:
> Just to put my two cents in...
>
> It's a matter of to be or not to be (ACID (by default)).
>
> With delayed_commits=true, data operations aren't durable anymore.
> Consequently, if it's the default setting, some people might say that
> CouchDB does not meet ACID requirements. People mostly tend to simplify.
> We will hardly be able to eliminate (sometimes vicious) superficiality,
> but we rather should face the fact that such partially true assertions
> may be harmful.
>
> Take MySQL as an example: there are (still) people stating that MySQL is
> not ACID compliant and doesn't support transactions. They are partially
> right with that: it's true for the default storage engine (MyISAM), but
> definitely not for InnoDB.
>
> With choosing stronger guarantees by default--as long as it goes in line
> with basic design decisions--we just eliminate any room for such
> confusion (or maybe even FUD that is spread by competitors). Basically,
> when comparing with other databases, that's way more important than a
> higher rank in an inadequate performance benchmark (pissing contest).
>
> - Klaus
>
>
> On Tue, 2010-07-06 at 16:43 +0200, Benoit Chesneau wrote:
>> I would prefer to put delayed_commits=false too, to keep the promise
>> we give to our users. We can't say on one side we are better than
>> mongo for this while a simple power failure may result in lost of data
>> by default (even if we are better since dbs won't be corrupted).
>>
>> The default should be the strongest imo. Like every os should be
>> secure by default, we should  let the user know, we do the best *by
>> default* to make sure data are safe on the disk. While they still have
>> the possibility to bypass this "security" . But in this case, this is
>> a choice.
>>
>> For those who worry about the marketing, this is also a good point of
>> differentiation compared to others dbs. (/me remove his marketing hat)
>> .
>>
>> - benoit
>
>
>

Re: RFC: Release 1.0

On Jul 6, 2010, at 11:44 AM, Noah Slater wrote:

> Hey,
> 
> This has already been exhaustively discussed on the mailing list, so this is 
> more of a courtisy than anything else. Unless anyone has any significant 
> objections, I will be cutting trunk for the 1.0 release tomorrow, and will 
> call a vote soon after.
> 

The only thing I can think of that's worth wrapping up is the 
delayed_commits=true conversation on the other thread. I have to say, Klaus's 
latest argument is convincing.

Chris

Re: delayed_commits false

2010-07-06 Thread Klaus Trainer

Just to put my two cents in...

It's a matter of to be or not to be (ACID (by default)).

With delayed_commits=true, data operations aren't durable anymore.
Consequently, if it's the default setting, some people might say that
CouchDB does not meet ACID requirements. People mostly tend to simplify.
We will hardly be able to eliminate (sometimes vicious) superficiality,
but we rather should face the fact that such partially true assertions
may be harmful.

Take MySQL as an example: there are (still) people stating that MySQL is
not ACID compliant and doesn't support transactions. They are partially
right with that: it's true for the default storage engine (MyISAM), but
definitely not for InnoDB.

With choosing stronger guarantees by default--as long as it goes in line
with basic design decisions--we just eliminate any room for such
confusion (or maybe even FUD that is spread by competitors). Basically,
when comparing with other databases, that's way more important than a
higher rank in an inadequate performance benchmark (pissing contest).

- Klaus

On Tue, 2010-07-06 at 16:43 +0200, Benoit Chesneau wrote:
> I would prefer to put delayed_commits=false too, to keep the promise
> we give to our users. We can't say on one side we are better than
> mongo for this while a simple power failure may result in lost of data
> by default (even if we are better since dbs won't be corrupted).
> 
> The default should be the strongest imo. Like every os should be
> secure by default, we should  let the user know, we do the best *by
> default* to make sure data are safe on the disk. While they still have
> the possibility to bypass this "security" . But in this case, this is
> a choice.
> 
> For those who worry about the marketing, this is also a good point of
> differentiation compared to others dbs. (/me remove his marketing hat)
> .
> 
> - benoit

Re: RFC: Release 1.0


On Jul 6, 2010, at 11:44 AM, Noah Slater wrote:

> Hey,
> 
> This has already been exhaustively discussed on the mailing list, so this is 
> more of a courtisy than anything else. Unless anyone has any significant 
> objections, I will be cutting trunk for the 1.0 release tomorrow, and will 
> call a vote soon after.
> 

w00t times 1.0

> Thanks,
> 
> N

RFC: Release 1.0

2010-07-06 Thread Noah Slater

Hey,

This has already been exhaustively discussed on the mailing list, so this is 
more of a courtisy than anything else. Unless anyone has any significant 
objections, I will be cutting trunk for the 1.0 release tomorrow, and will call 
a vote soon after.

Thanks,

N

[jira] Commented: (COUCHDB-817) Natively support coffeescript

2010-07-06 Thread Chris Anderson (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885571#action_12885571
 ] 

Chris Anderson commented on COUCHDB-817:


Here's a link to a Ruby query server:

http://github.com/mattly/couchdb-ruby-query-server

Also, here is the test for the current JS and Erlang query servers:

http://svn.apache.org/repos/asf/couchdb/trunk/test/view_server/query_server_spec.rb

> Natively support coffeescript
> -
>
> Key: COUCHDB-817
> URL: https://issues.apache.org/jira/browse/COUCHDB-817
> Project: CouchDB
>  Issue Type: New Feature
>Reporter: Matt Parker
>
> i'd love to be able to put coffeescript map and reduce function/files 
> directly into my ddoc, instead of having to compile them first.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: delayed_commits false