Re: [ANNOUNCE] Apache CouchDB 1.0.0 has been released
Congratulations!!! On Wed, Jul 14, 2010 at 9:04 AM, James Marca wrote: > Congratulations and thanks to all the developers for all the hard work > putting together this excellent tool. > > James Marca > > On Wed, Jul 14, 2010 at 01:57:50PM +0100, Noah Slater wrote: > > Hello, > > > > Apache CouchDB 1.0.0 has been released and is available for download: > > > > http://couchdb.apache.org/downloads.html > > > > This is a huge milestone for the CouchDB community, and we'd like to > thank every single person who's helped us get this far. This project would > be nothing without its community, and we are fortunate enough to be blessed > with a very healthy one. > > > > Changes in this release: > > > > * More efficient header commits. > > * Use O_APPEND to save lseeks. > > * Faster implementation of pread_iolist(). Further improves performance > on > >concurrent reads. > > * Added authentication caching > > * Faster default view collation. > > * Added option to include update_seq in view responses. > > > > This builds on the changes made in 0.11.1, also released today. > > > > Apache CouchDB is a document-oriented database that can be queried and > indexed in a MapReduce fashion using JavaScript. CouchDB also offers > incremental replication with bi-directional conflict detection and > resolution. > > > > CouchDB provides a RESTful JSON API than can be accessed from any > environment that allows HTTP requests. There are myriad third-party client > libraries that make this even easier from your programming language of > choice. CouchDB’s built in Web administration console speaks directly to the > database using HTTP requests issued from your browser. > > > > CouchDB is written in Erlang, a robust functional programming language > ideal for building concurrent distributed systems. Erlang allows for a > flexible design that is easily scalable and readily extensible. > > > > Relax and prosper, > > > > N > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- David W. Van Couvering http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Re: Nightly and binary builds
+1 Netbeans did this and it was a huge success with our users On Thu, Jan 21, 2010 at 1:55 PM, Chris Anderson wrote: > On Thu, Jan 21, 2010 at 12:20 PM, Ben Schwarz > wrote: > > Couch DBX is v0.10 and Mac only – therefore it is not the answer I was > looking for. > > > > I think we'd do well to add links from our homepage to > double-click-and-run all-in-one packages for mac, linux, and windows. > (as well as plain binaries for people interested in that). > > If we can help the maintainers of those projects start providing > nightly builds, that'd be even better. > > Chris > > > > > > > > > On 22/01/2010, at 12:39 AM, Noah Slater wrote: > > > >> > >> On 21 Jan 2010, at 09:30, Ben Schwarz wrote: > >> > >>> I understand how to build couch now. I don't want to follow this > process ever again. > >>> No end user wishing to test nighties should have to go through such a > process. > >>> > >>> If it means bundling erlang, then so be it. > >> > >> I will re-itterate that if this is something you really care about, a > patch would be fantastic. > >> > >> Did you check out CouchDB X? > > > > > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io > -- David W. Van Couvering http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Re: Where to add documentation for bulk updates
Thanks for fixing this, Brian. I'm not sure I'm totally happy with these semantics. Unless I am missing something (more than possible as I'm still learning CouchDB), for a bulk update with N documents, you would have to do 1 round-trip for the update and N round-trips to check for conflicts (or, if not using all-or-nothing, N round-trips to check and see if the update was successful or not). Isn't there any way for the response to a bulk update to tell you which documents have conflicts or failures? If what I'm saying above is correct, I would probably just do regular PUTs and skip bulk update functionality altogether. David On Tue, Mar 24, 2009 at 7:08 AM, Brian Candler wrote: > On Tue, Mar 24, 2009 at 08:27:09AM +, Chris Anderson wrote: > > Don't be afraid to edit it! > > I just didn't want to stomp on it while someone else was working, and > create > more edit conflicts :-) > > I have fixed it now, except that I still don't know whether the > all_or_nothing commit boundary is preserved during replication. > > Regards, > > Brian. > -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Re: Where to add documentation for bulk updates
Fixed. Thanks for catching this. Obviously I should have tested this, but
I am very busy right now, and I wanted to get this doc out in time for the
release.
David
On Mon, Mar 23, 2009 at 10:40 AM, Brian Candler wrote:
> On Mon, Mar 23, 2009 at 09:59:56AM -0700, David Van Couvering wrote:
> >OK, thanks, I didn't read down far enough. I fixed the conflict and
> >made some more updates to make the overall section more clean and
> >consistent, and added some more meat to the examples.
>
> Cheers. Could you also fix the all-or-nothing documentation while you're at
> it. Experimentation suggests it doesn't work if you add
> ?all_or_nothing=true
> or ?all-or-nothing=true to the URL; rather you need to put
> {"all_or_nothing":true} as part of the POSTed JSON.
>
> Demo:
>
> $ curl http://localhost:5984/
> {"couchdb":"Welcome","version":"0.9.0a757393"}
> $ DB="http://127.0.0.1:5984/tstconf";
> $ curl -X PUT "$DB"
> {"ok":true}
> $ curl -X PUT -d '{"name":"fred"}' "$DB/person"
> {"ok":true,"id":"person","rev":"1-877727288"}
> $ curl -X POST -d
> '{"docs":[{"_id":"person","_rev":"1-877727288","name":"jim"}]}'
> "$DB/_bulk_docs?all_or_nothing=true"
> [{"id":"person","rev":"2-3595405"}]
> $ curl -X POST -d
> '{"docs":[{"_id":"person","_rev":"1-877727288","name":"trunky"}]}'
> "$DB/_bulk_docs?all_or_nothing=true"
> [{"id":"person","error":"conflict","reason":"Document update conflict."}]
> $ curl -X POST -d
> '{"docs":[{"_id":"person","_rev":"1-877727288","name":"trunky"}]}'
> "$DB/_bulk_docs?all-or-nothing=true"
> [{"id":"person","error":"conflict","reason":"Document update conflict."}]
>
> But:
>
> $ curl -X POST -d
> '{"all_or_nothing":true,"docs":[{"_id":"person","_rev":"1-877727288","name":"trunky"}]}'
> "$DB/_bulk_docs"
> [{"id":"person","rev":"2-2835283254"}]
> $ curl "$DB/person?conflicts=true"
>
> {"_id":"person","_rev":"2-3595405","name":"jim","_conflicts":["2-2835283254"]}
>
> Regards,
>
> Brian.
>
--
David W. Van Couvering
I am looking for a senior position working on server-side Java systems.
Feel free to contact me if you know of any opportunities.
http://www.linkedin.com/in/davidvc
http://davidvancouvering.blogspot.com
http://twitter.com/dcouvering
Re: Where to add documentation for bulk updates
Yes, thanks, will fix.
David
On Mon, Mar 23, 2009 at 10:40 AM, Brian Candler wrote:
> On Mon, Mar 23, 2009 at 09:59:56AM -0700, David Van Couvering wrote:
> >OK, thanks, I didn't read down far enough. I fixed the conflict and
> >made some more updates to make the overall section more clean and
> >consistent, and added some more meat to the examples.
>
> Cheers. Could you also fix the all-or-nothing documentation while you're at
> it. Experimentation suggests it doesn't work if you add
> ?all_or_nothing=true
> or ?all-or-nothing=true to the URL; rather you need to put
> {"all_or_nothing":true} as part of the POSTed JSON.
>
> Demo:
>
> $ curl http://localhost:5984/
> {"couchdb":"Welcome","version":"0.9.0a757393"}
> $ DB="http://127.0.0.1:5984/tstconf";
> $ curl -X PUT "$DB"
> {"ok":true}
> $ curl -X PUT -d '{"name":"fred"}' "$DB/person"
> {"ok":true,"id":"person","rev":"1-877727288"}
> $ curl -X POST -d
> '{"docs":[{"_id":"person","_rev":"1-877727288","name":"jim"}]}'
> "$DB/_bulk_docs?all_or_nothing=true"
> [{"id":"person","rev":"2-3595405"}]
> $ curl -X POST -d
> '{"docs":[{"_id":"person","_rev":"1-877727288","name":"trunky"}]}'
> "$DB/_bulk_docs?all_or_nothing=true"
> [{"id":"person","error":"conflict","reason":"Document update conflict."}]
> $ curl -X POST -d
> '{"docs":[{"_id":"person","_rev":"1-877727288","name":"trunky"}]}'
> "$DB/_bulk_docs?all-or-nothing=true"
> [{"id":"person","error":"conflict","reason":"Document update conflict."}]
>
> But:
>
> $ curl -X POST -d
> '{"all_or_nothing":true,"docs":[{"_id":"person","_rev":"1-877727288","name":"trunky"}]}'
> "$DB/_bulk_docs"
> [{"id":"person","rev":"2-2835283254"}]
> $ curl "$DB/person?conflicts=true"
>
> {"_id":"person","_rev":"2-3595405","name":"jim","_conflicts":["2-2835283254"]}
>
> Regards,
>
> Brian.
>
--
David W. Van Couvering
I am looking for a senior position working on server-side Java systems.
Feel free to contact me if you know of any opportunities.
http://www.linkedin.com/in/davidvc
http://davidvancouvering.blogspot.com
http://twitter.com/dcouvering
Re: Where to add documentation for bulk updates
On Mon, Mar 23, 2009 at 7:23 AM, Brian Candler wrote: > Scroll down to "Transactional Semantics with Bulk Updates" (either in > normal > view or raw view) > > After that section I see: > > /!\ '''Edit conflict - other version:''' > > Followed by a different version of the same para, then > > /!\ '''Edit conflict - your version:''' > > /!\ '''End of edit conflict''' > > I believe the second version is more accurate, but I look forward to seeing > some definitive information here. > OK, thanks, I didn't read down far enough. I fixed the conflict and made some more updates to make the overall section more clean and consistent, and added some more meat to the examples. > > Also, I have a particular question. The wiki says that the old atomic > _bulk_docs was removed because it could not be implemented on a sharded > cluster without resorting to two-phase commits. However, I cannot see how > the new semantics of _bulk_docs?all_or_nothing=true can be implemented > across such a cluster without two-phase commit either. > That's a good point. I am pretty sure what you actually get all_or_nothing_per_shard :). Since CouchDB doesn't do its own sharding right now, I am not sure if we need to document this? David > Regards, > > Brian. > -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Re: Where to add documentation for bulk updates
That's pretty funny there was a conflict editing this document :). Anyway, I just went to the page and I couldn't find the problem - the page looks clean to me. Can you point me to how to see the issue if you are still seeing it? I don't have an answer to your other question, what happens when you use _bulk_docs on a single document. I'll leave that to others more knowledgable than I. David On Sun, Mar 22, 2009 at 3:02 PM, Brian Candler wrote: > On Sun, Mar 22, 2009 at 07:37:01AM -0700, David Van Couvering wrote: > > OK, I updated the page. Can someone please make sure my example response > is > > correct? I gleaned it best as I could from the existing docs. In > > particular, is the format of the request for all-or-nothing correct, and > is > > the conflict response correct? > > http://wiki.apache.org/couchdb/HTTP_Document_API > > Meta edit conflict warning: the wiki page itself shows a wiki edit conflict > at the moment :-) > > Aside: if I read this correctly, it seems you can now get completely > different semantics for updating a single document, if instead of using > PUT, > you POST it to _bulk_docs?all_or_nothing=true. In the latter case, if > someone else has change the doc in the mean time, you'll get both versions > saved. > > In some ways you can now argue that PUT has the unusual semantics of > rejecting a document update if the _rev is wrong. PUT gives a sort of > single > node "transaction" which ensures your document remains conflict-free, but > only so long as you don't include replication into the mix. Wasn't this > also > the case for the old _bulk_docs transactions? > > Regards, > > Brian. > -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Re: Where to add documentation for bulk updates
OK, I updated the page. Can someone please make sure my example response is correct? I gleaned it best as I could from the existing docs. In particular, is the format of the request for all-or-nothing correct, and is the conflict response correct? David On Sun, Mar 22, 2009 at 1:44 AM, Jan Lehnardt wrote: > Hi David, > > > On 22 Mar 2009, at 05:32, David Van Couvering wrote: > > Hi, all. I was going to do a first draft of the documentation for the >> _bulk_docs changes Damien made. I didn't see an obvious place to put this >> page. Is there a place this *should* go? Otherwise I'll just put it >> somewhere that seems reasonable. >> > > The current bulk_docs documentation is on > http://wiki.apache.org/couchdb/HTTP_Document_API > under POST. For now I think this is a good place to document the new > behaviour. > > Also, thanks :) > > Cheers > Jan > -- > > -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Where to add documentation for bulk updates
Hi, all. I was going to do a first draft of the documentation for the _bulk_docs changes Damien made. I didn't see an obvious place to put this page. Is there a place this *should* go? Otherwise I'll just put it somewhere that seems reasonable. Thanks, David
Re: Bulk updates and eventual consistency
OK, thanks, that is clear. It's sort of guaranteeing a "binary compatibility" between single node and multi-node solutions, where you don't paint yourself into a corner when just working in a single node. David On Thu, Mar 19, 2009 at 12:03 AM, Antony Blakey wrote: > > On 19/03/2009, at 4:20 PM, David Van Couvering wrote: > > My apologies if this was already answered in that very long thread, but >> perhaps someone can summarize for me... >> > > It is intended that the difference between single-node and multi-node > cluster operation not be exposed to clients, to ensure that there are no > single-node-only applications which don't scale to clustered operation. This > means that "deployments where you are not doing replication" isn't a > relevant distinction as far as the CouchDB model is concerned. > > IMO this is a questionable decision, but I'm in the minority. > > Antony Blakey > - > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > The difference between ordinary and extraordinary is that little extra. > > > -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Bulk updates and eventual consistency
Hi, all. I'm working on updating the Wiki to describe the new behavior of bulk updates. I read the very (very) long thread about Damien's change to the transactional semantics around _bulk_docs, and I understand the situation pretty well (I think). But there's one part of the discussion that I wanted to make sure I had correct. My understanding is that one motivation for bulk update may be because you have referential dependencies between docs. If there are no conflicts, then you can be assured those references will be consistent on the database where you do the bulk update (with all-or-nothing), *but* they may not immediately be consistent on replicas. This is because a bulk update is not replicated all-or-nothing, but instead each document is replicated independently, in an unspecified order. So you will have a temporary state of affairs where the references between documents may be inconsistent, but eventually they do become consistent (for that particular bulk update). *But* if you *do* have conflicts in a bulk update, then it is quite possible that the choice of winners for the conflict will cause a referential inconsistency between documents. In this case, the inconsistency will *not* automatically become eventually consistent, but will require intervention by the application to resolve the documents to a consistent state. This can happen even when you are not using replication at all, but you have two simultaneous sessions update the same document. In the previous implementation, bulk_update rolled back if there were any "local" conflicts, so you were guaranteed of referential consistency between docs on the database instance where you applied the bulk update. However, you could still end up in a pickle if replication caused a conflict -- now you are back in the same place with referential inconsistency that has to be manually resolved. Do I have that right? I am uncomfortable about asking the next question, as I feel I am opening up a can of worms, but I am missing what problem was solved by allowing all-or-nothing to succeed on conflicts. It seems like in both models you have eventual consistency and interim states where documents are inconsistent, but at least with the old approach you were guaranteed consistency on the database instance where you did the bulk update. That seems like it could be pretty handy, particularly for deployments where you are not doing replication. My apologies if this was already answered in that very long thread, but perhaps someone can summarize for me... Thanks, David -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
[jira] Commented: (COUCHDB-223) Document a way to find out failed writes fro bulk requests and async writes
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683328#action_12683328 ] David Van Couvering commented on COUCHDB-223: - Here's the first draft of this. It is missing example code, but I thought you could review the overall description of the problem and new semantics while I'm poking around trying to figure out what the example code should look like. The tests are written in JavaScript, and I can pull that code for an example, but shouldn't I also describe what the underlying HTTP request should look like? In previous releases of CouchDB, bulk updates were transactional - in particular, all requests in a bulk update failed if any request failed or was in conflict. There were a couple of problems with this approach: - This doesn't actually work with replication. Replication doesn't provide the same transactional semantics, so downstream replicas won't see "all-or-nothing" transactional semantics. Instead, they will see documents in an inconsistent state until replication of all documents involved in the bulk update completes. With bidirectional replication it can get even worse, because you can get edit conflicts that must be fixed manually. - If your database is partioned (aka "sharded"), different documents within the transaction could live on different nodes in the cluster, and these kinds of transactional semantics don't work unless you use heavy, non-scalable approaches like two-phase commit. With release 0.9 of CouchDB, transactional semantics have been changed to make sure CouchDB works well in replicated and partitioned environments. There are now two transactional models supported: QUESTION: how does the user control which transactional model is used? - all-or-nothing - When using _bulk_docs to update a set of documents, either all the documents will commit successfully or none will. However, it does not do conflict checking the documents will be committed even if there are conflicts. Conflicting versions of the document will be saved. To use this approach, set the all_or_nothing flag when issuing a _bulk_docs request. TODO: Provide example code here... - non-atomic - In this mode, some documents may successfully be saved and some may not, and it is up to the application to check that all documents were successfully saved/updated. > Document a way to find out failed writes fro bulk requests and async writes > --- > > Key: COUCHDB-223 > URL: https://issues.apache.org/jira/browse/COUCHDB-223 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Reporter: Jan Lehnardt >Priority: Blocker > Fix For: 0.9 > > > A bulk docs request fails if one of the containing requests fail. In favour > of multi-node partitioning, this behaviour goes away and bulk writes will > behave a lot like and async writes and we should document the preferred way > for clients to find failed writes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed writes fro bulk requests and async writes
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683321#action_12683321 ] David Van Couvering commented on COUCHDB-223: - That's odd. In Apache Derby, anybody who went through a quick signup process could own issues, even if they weren't contributors. Anyway, I was looking at doing a first draft of this, but couldn't really figure out where to put it in the Wiki. Perhaps it could go into howto, but is there somewhere I'm missing that already talks about bulk_docs functionality where I could just append/update the information? Thanks! > Document a way to find out failed writes fro bulk requests and async writes > --- > > Key: COUCHDB-223 > URL: https://issues.apache.org/jira/browse/COUCHDB-223 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Reporter: Jan Lehnardt >Priority: Blocker > Fix For: 0.9 > > > A bulk docs request fails if one of the containing requests fail. In favour > of multi-node partitioning, this behaviour goes away and bulk writes will > behave a lot like and async writes and we should document the preferred way > for clients to find failed writes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed writes fro bulk requests and async writes
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682559#action_12682559 ] David Van Couvering commented on COUCHDB-223: - I'd assign myself this issue but it says I don't have permission to work on it. I scanned the CouchDB pages, I can't find anything obvious about how to get permission. Can someone give me permission? Thanks... > Document a way to find out failed writes fro bulk requests and async writes > --- > > Key: COUCHDB-223 > URL: https://issues.apache.org/jira/browse/COUCHDB-223 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Reporter: Jan Lehnardt >Priority: Blocker > Fix For: 0.9 > > > A bulk docs request fails if one of the containing requests fail. In favour > of multi-node partitioning, this behaviour goes away and bulk writes will > behave a lot like and async writes and we should document the preferred way > for clients to find failed writes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Getting a hang in make install after svn update (MacOS)
First of all, sorry about the duplicate email, I had to reboot my machine hard and thought the email hadn't been sent. Secondly, more info: it turns out that the default 'libtool' created in the root directory of couchdb was the problem. If I use /usr/local/bin/libtool instead, it works much better, and make install is successful. So perhaps there is some subtlety in my environment and how configure works where it is getting the "wrong" libtool? David On Mon, Mar 16, 2009 at 9:36 PM, David Van Couvering wrote: > Hi, all. I am trying to get couchdb going again after an svn update. I am > following the instructions in the README: > > - svn update > - bootstrap > - configure > - make > - make install > > It's the last step that's giving me problems. I am getting this output > (notice that launchd socket is -1), and an X process is running, and then it > just hangs... > > Xquartz starting: > X.org Release 7.2 > X.Org X Server 1.3.0-apple22 > Build Date: 20080821 > Launchd socket fd: -1 > Could not init font path element /Library/Fonts, removing from list! > Could not init font path element /System/Library/Fonts, removing from list! > > Any tips? Is there some cleanup I should be doing? > > Thanks, > > David > > -- > David W. Van Couvering > > I am looking for a senior position working on server-side Java systems. > Feel free to contact me if you know of any opportunities. > > http://www.linkedin.com/in/davidvc > http://davidvancouvering.blogspot.com > http://twitter.com/dcouvering > -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Getting a hang in make install after svn update (MacOS)
Hi, all. I am trying to get couchdb going again after an svn update. I am following the instructions in the README: - svn update - bootstrap - configure - make - make install It's the last step that's giving me problems. I am getting this output (notice that launchd socket is -1), and an X process is running, and then it just hangs... Xquartz starting: X.org Release 7.2 X.Org X Server 1.3.0-apple22 Build Date: 20080821 Launchd socket fd: -1 Could not init font path element /Library/Fonts, removing from list! Could not init font path element /System/Library/Fonts, removing from list! Any tips? Is there some cleanup I should be doing? Thanks, David -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
'make install' hangs on Mac after svn update
Hi, all . I'm on MacOSX Leopard and am trying to update my sources for couchdb. I followed the README and did the following: - svn update - bootstrap - configure - make - make install The last step is where I am having a problem: /bin/sh ../../libtool --mode=install /usr/bin/install -c ' couch_erl_driver.la' '/usr/local/lib/couchdb/erlang/lib/couch-0.9.0a743231-incubating/priv/lib/ couch_erl_driver.la' ../../libtool: line 778: X--mode=install: command not found ../../libtool: line 944: *** Warning: inferring the mode of operation is deprecated.: command not found ../../libtool: line 945: *** Future versions of Libtool will require --mode=MODE be specified.: command not found ../../libtool: line 6099: X/usr/bin/install: No such file or directory ../../libtool: line 6117: X/usr/bin/install: No such file or directory ../../libtool: line 6168: X-c: command not found ../../libtool: line 6200: X/usr/local/lib/couchdb/erlang/lib/couch-0.9.0a743231-incubating/priv/lib/ couch_erl_driver.la: No such file or directory Xquartz starting: X.org Release 7.2 X.Org X Server 1.3.0-apple22 Build Date: 20080821 Launchd socket fd: -1 Could not init font path element /Library/Fonts, removing from list! Could not init font path element /System/Library/Fonts, removing from list! I get an "X" mouse icon (looks like it's from an X windowing system) and then it just hangs... Any tips? Is there some process I should be killing first? Thanks, David -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
[jira] Commented: (COUCHDB-223) Document a way to find out failed writes fro bulk requests and async writes
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682200#action_12682200 ] David Van Couvering commented on COUCHDB-223: - As an attempt to help contribute to the 0.9 release, I'd be happy to document this if I understood better what the issue was. The description is a bit cryptic. Is there an email thread that discusses this further? > Document a way to find out failed writes fro bulk requests and async writes > --- > > Key: COUCHDB-223 > URL: https://issues.apache.org/jira/browse/COUCHDB-223 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Reporter: Jan Lehnardt >Priority: Blocker > Fix For: 0.9 > > > A bulk docs request fails if one of the containing requests fail. In favour > of multi-node partitioning, this behaviour goes away and bulk writes will > behave a lot like and async writes and we should document the preferred way > for clients to find failed writes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Partitioning use cases
> > I'm sure I'm missing some things (in particular, I don't fully understand > > the discussion about configuring the topology differently depending upon > > performance needs - I wonder if that's an implementation-specific > detail). > > From what I understand, the initial idea was to have the partitioning > be fairly static and not try to tackle all the dynamic challenges > up-front. So initially a topology would be decided upon based upon the > needs of a particular dataset (data-intensive, map/reduce intensive, > etc) and remain fairly stable. > I guess what I'm trying to understand is this idea of a "tree" topology - how exactly does that work. What are the internal nodes of the tree - are they "meta tables" that contain pointers to the next level of the tree and or the leaf nodes where the tables contain actual data - ala BigTable? > > > > One way perhaps I could help is to work on an API that maps a key to a > node > > (with some sort of pluggable interface for various consistent hashing > > algorithms, starting maybe with Chord, given that there is an existing > > implementation in Erlang called Chordial - > > http://dawsdesign.com/drupal/chordial) > > I think having a pluggable interface for choosing the consistent > hashing algorithm is a good idea. Chord looks very nice for systems > where nodes are dynamically added and removed all the time. I think > that's a bit more advanced than the initial implementation is shooting > for but maps very well to the long-term goal with CouchDB as a true > distributed database. > > These are my thoughts, so if they don't map with the opinions of the > rest of the community please speak up. > OK. As much as I would like to jump right in, I have a slight problem in that I am completely new to Erlang. So I will need to spend some time coming up to speed with Erlang. I think I'll approach this in two ways - walk through the tutorials and then try fixing some bugs. I can't say when I will feel capable to build a pluggable interface, but I'll do what I can. David > > Ben > -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Partitioning use cases
Hi, all. I did a first pass at the high-level use cases, both to start with and then looking forward. http://wiki.apache.org/couchdb/Partitioning_proposal I'm sure I'm missing some things (in particular, I don't fully understand the discussion about configuring the topology differently depending upon performance needs - I wonder if that's an implementation-specific detail). But hopefully this helps. One way perhaps I could help is to work on an API that maps a key to a node (with some sort of pluggable interface for various consistent hashing algorithms, starting maybe with Chord, given that there is an existing implementation in Erlang called Chordial - http://dawsdesign.com/drupal/chordial) David -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Re: CouchDB and clustering
This is a great summary of the goals. What I would like to see (and what I'm offering to write up) is a set of scenarios/use cases, and use this to make sure there is agreement on the functionality, to help guide/frame the approach, and to exercise the design we come up with. Unless there are any objections, I'll go ahead and start putting something together on the Wiki. David On Thu, Feb 26, 2009 at 3:56 PM, Ben Browning wrote: > I think I've captured, at least at a high-level, the general consensus > on partitioning here: > > http://wiki.apache.org/couchdb/Partitioning_proposal > > There's not a lot of actual implementation details yet since those > still need to be worked through and I'm planning to concentrate on the > prerequisite Erlang API first. Feel free to edit as needed. > > Ben > -- David W. Van Couvering I am looking for a senior position working on server-side Java systems. Feel free to contact me if you know of any opportunities. http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
Re: Helping out
Great, thanks all! I'll poke around and see if I can find a way in that is most effective for me and for you all. Talk to you soon. David On Wed, Feb 11, 2009 at 7:52 AM, Robert Dionne wrote: > http://wiki.apache.org/couchdb/Development > > > > > > On Feb 11, 2009, at 10:45 AM, Damien Katz wrote: > > Hi Dave. Sorry about the layoff. That sucks. :( >> >> The best way to get involved is to hang out and participate here on the >> mailing lists. Also the wiki has a lot of information, and not all of it >> accurate or up to date, so a good way to get started and to help the >> community is to use the wiki docs yourself and actively update anything that >> is wrong or confusing or could just be worded better. Documentation >> improvements are a big help. >> >> As far as getting started hacking on the source, I thought we had a page >> on the wiki for how to get started hacking, but I can't find it now. Anyone >> else got pointers? >> >> -Damien >> >> >> >> On Feb 11, 2009, at 12:27 AM, David Van Couvering wrote: >> >> Hello. I've been following CouchDB from the sidelines for a while but >>> haven't been able to put much time into it. >>> >>> Recently, however, Sun laid me off, and I thought this would be a good >>> opportunity to get a little more engaged. >>> >>> No better way, IMHO, than to help out with the project. FYI, I'm already >>> a >>> committer to Apache Derby, although I haven't been active there in the >>> past >>> few years. >>> >>> I was looking at your road map and it looked like you want to get a lot >>> of >>> documentation written. I was thinking that would be a great way for me >>> to >>> start learning CouchDB. Is there a specific document that you would like >>> to >>> me to try my hand at? Also, what are your processes, technologies and >>> standards around documentation? >>> >>> I can also start poking around at your bug list and perhaps offer some >>> patches to get my feet wet. Is there anything in particular that you >>> would >>> like someone to focus on? I don't have an Erlang background, although >>> I'm >>> interested in learning. My background is server-side Java and databases, >>> for the most part. >>> >>> I look forward to hearing from you. Meanwhile I'll try to get a build >>> going >>> and see how that goes. >>> >>> All the best, >>> >>> David >>> >>> -- >>> David W. Van Couvering >>> http://davidvancouvering.blogspot.com >>> >> >> > -- David W. Van Couvering http://davidvancouvering.blogspot.com
Helping out
Hello. I've been following CouchDB from the sidelines for a while but haven't been able to put much time into it. Recently, however, Sun laid me off, and I thought this would be a good opportunity to get a little more engaged. No better way, IMHO, than to help out with the project. FYI, I'm already a committer to Apache Derby, although I haven't been active there in the past few years. I was looking at your road map and it looked like you want to get a lot of documentation written. I was thinking that would be a great way for me to start learning CouchDB. Is there a specific document that you would like to me to try my hand at? Also, what are your processes, technologies and standards around documentation? I can also start poking around at your bug list and perhaps offer some patches to get my feet wet. Is there anything in particular that you would like someone to focus on? I don't have an Erlang background, although I'm interested in learning. My background is server-side Java and databases, for the most part. I look forward to hearing from you. Meanwhile I'll try to get a build going and see how that goes. All the best, David -- David W. Van Couvering http://davidvancouvering.blogspot.com
