On Jan 5, 2009, at 2:38 PM, Chris Anderson wrote:
On Mon, Jan 5, 2009 at 11:32 AM, Damien Katz dam...@apache.org
wrote:
1) delayed commit (what you did last night)
2) fsync() commit (what I suspect Couch did on and around 0.8)
3) optional F_FULLSYNC commit, on OS X and any other platform
What happens on startup after the user puts bad values into the ini
file?
-Damien
On Jan 13, 2009, at 11:36 AM, Ulises wrote:
My question is what problem does this solve?
Users shooting themselves in the foot by providing wrong config
parameters, better error reporting for, say, when the
Chunked isn't allowed right now. Why are you sending a file chunked?
-Damien
On Jan 16, 2009, at 5:27 AM, Benoit Chesneau wrote:
On Fri, Jan 16, 2009 at 11:15 AM, Benoit Chesneau
bchesn...@gmail.com wrote:
On Fri, Jan 16, 2009 at 1:07 AM, Damien Katz dam...@apache.org
wrote:
I checked
On Jan 16, 2009, at 8:37 AM, Benoit Chesneau wrote:
On Fri, Jan 16, 2009 at 1:55 PM, Damien Katz dam...@apache.org
wrote:
Chunked isn't allowed right now. Why are you sending a file chunked?
-Damien
Chunked seem the only method to send a big files in with curl in
command line, since
Here is a draft of the board report that's due soon. What should I add
to the report?
-Damien
CouchDB is a distributed document-oriented database system written in
Erlang. The project graduated to TLP in November 2008 and Damien Katz
was approved as the Apache CouchDB PMC
I think we shouldn't end documents with newlines, because a canonical
representation of json won't included a trailing newline, which can
cause complications with end to end integrity checks.
-Damien
Along those lines, I hereby present four options and an informal vote:
* Accept the
On Jan 26, 2009, at 12:28 PM, Damien Katz wrote:
I think we shouldn't end documents with newlines, because a
canonical representation of json won't included a trailing newline,
which can cause complications with end to end integrity checks.
-Damien
Along those lines, I hereby present four
Geir, there was a decision made by the PMCs to change the transaction
model to support partitioned databases. It is a change I am currently
working on.
-Damien
On Feb 4, 2009, at 8:46 PM, Geir Magnusson Jr. wrote:
and original question #2?
geir
On Feb 4, 2009, at 8:38 PM, Antony Blakey
Ideally yes, but real time communication with everyone together is
damn useful.
-Damien
On Feb 5, 2009, at 2:07 AM, Ted Leung wrote:
Uh, project decisions are supposed to be made in the public mailing
lists...
Ted
On Feb 4, 2009, at 6:51 PM, Damien Katz wrote:
This decision
probably be private.
-Damien
(By the way - from my count, not all PMC members are even on the
PMC's private@ list, so I have *no clue* where project private
discussion - like new committer candidates - are even discussed)
geir
On Feb 5, 2009, at 2:11 AM, Damien Katz wrote
Just to clarify for the sake of the community as a whole, any
important decisions about the code and project MUST be discussed on
the mailing list.
IRC, chat, etc are fine for helping each other understand the issues
and so forth, but ultimately project discussions should move to the
I'm working on a branch that implements couchdb the security features
with replication. It not done yet, but anyone is welcome to look at
the branch in /branches/rep_security.
In this patch I am attempting to implement new transactions models.
The old transaction model has you all or
we currently have. It's possible to keep supporting it,
but it doesn't work with any of CouchDB's distributed features. It's
only appropriate for a single node instance, even a hot standby slave
will have inconsistent states.
-Damien
On Feb 7, 2009, at 10:47 AM, Damien Katz damien_k
Part of the larger replication security work (branches/rep_security)
is to allow rev histories to be trimmed back to an arbitrary length.
Without this, revision histories must grow and grow, each update to a
doc adds a new revision to the history. So if a document is edited 1
million
On Feb 7, 2009, at 5:08 PM, Geir Magnusson Jr. wrote:
On Feb 7, 2009, at 11:22 AM, Damien Katz wrote:
On Feb 7, 2009, at 11:02 AM, Geir Magnusson Jr. wrote:
Thanks for the info. Is there a third mode possible? Namely all
or nothing with conflict check, with the understanimg
On Feb 7, 2009, at 9:37 PM, Antony Blakey wrote:
On 08/02/2009, at 12:05 PM, Damien Katz wrote:
But if the replication doesn't complete, like in the middle you
lose your connection, then the downstream db is in an inconsistent
state and will be until you regain the connection
On Feb 7, 2009, at 11:59 PM, Antony Blakey wrote:
On 08/02/2009, at 3:07 PM, Damien Katz wrote:
I can't see why this needs to be the case. The fact that there are
peers that have an incomplete replication doesn't stop the master
taking updates - iff the updates to the master are multi
On Feb 8, 2009, at 12:37 AM, Antony Blakey wrote:
On 08/02/2009, at 3:52 PM, Damien Katz wrote:
No, CouchDB replication doesn't support replicating the
transactions. Never has, never will. That's more like transaction
log replication that's in traditonal dbs, a different beast.
So just
On Feb 8, 2009, at 1:20 AM, Antony Blakey wrote:
On 08/02/2009, at 4:35 PM, Damien Katz wrote:
So just to be clear, replication ignores MVCC?
No, it still uses MVCC, just not at transaction boundaries.
Surely MVCC is only about 'transactions'. Even if it's an issue of
on-disk ACID
On Feb 8, 2009, at 9:10 AM, Geir Magnusson Jr. wrote:
On Feb 7, 2009, at 7:45 PM, Damien Katz wrote:
On Feb 7, 2009, at 6:49 PM, Geir Magnusson Jr. wrote:
On Feb 7, 2009, at 6:05 PM, Damien Katz wrote:
On Feb 7, 2009, at 5:08 PM, Geir Magnusson Jr. wrote:
[snip]
I understand - my
On Feb 8, 2009, at 1:49 AM, Antony Blakey wrote:
On 08/02/2009, at 5:05 PM, Damien Katz wrote:
In this case it has nothing to do with update transactions. MVCC is
about each read operation having it's own snapshot of the database.
Sure, but the MVCC snapshots are created by update
I don't think it's strictly necessary, but it makes merging new edits
simpler and it significantly reduces the chances of collisions between
revision ids, there is less ambiguity. What downsides do your see?
-Damien
On Feb 8, 2009, at 2:28 PM, Adam Kocoloski wrote:
Hi Damien, it seems to
On Feb 8, 2009, at 7:38 PM, Antony Blakey wrote:
On 09/02/2009, at 1:08 AM, Damien Katz wrote:
On Feb 8, 2009, at 1:49 AM, Antony Blakey wrote:
On 08/02/2009, at 5:05 PM, Damien Katz wrote:
In this case it has nothing to do with update transactions. MVCC
is about each read operation
On Feb 8, 2009, at 7:14 PM, Antony Blakey wrote:
On 09/02/2009, at 1:08 AM, Damien Katz wrote:
Nope, each individual read operation gets a snapshot of the
database. When you are replicating, there is one read operation for
every document that must be sent. Each read request gives you
On Feb 8, 2009, at 9:24 PM, Chris Anderson wrote:
On Sun, Feb 8, 2009 at 5:54 PM, Damien Katz dam...@apache.org wrote:
It's possible to use MVCC for replication. You'll need to create
special
HTTP command to return you all the documents you are interested in
a single
request
that will require a
lot of effort.
-Damien
On Feb 9, 2009, at 6:03 AM, Antony Blakey wrote:
On 09/02/2009, at 1:07 PM, Damien Katz wrote:
would be a big problem of replicating huge databases. Everything
must come over in one transaction.
I doesn't *have* to come in one transaction, but I
On Feb 9, 2009, at 8:58 AM, Antony Blakey wrote:
On 10/02/2009, at 12:17 AM, Jan Lehnardt wrote:
On 9 Feb 2009, at 13:38, Antony Blakey wrote:
Antony, those sounds like interesting ideas, and I hope you can
get it working. But a one-way replicable db with full-consistency
guarantees is
The 0.9.0 release has been dragging on forever as I try to get the
replication security stuff working. Unfortunately I've stalled out on
it and I'm not sure when I'll be able to finish it to production
quality. Could be a week, could be a month. I've been feeling likes
its only a week away
-0500, Damien Katz wrote:
So I'm wondering if we should just forget it for 0.9.0 and release it
without. It won't be beta yet and the security stuff useless as it is
now now, but all the other stuff that's in 0.9 will still be there.
Thoughts please.
I would be inclined to wait a little
On Feb 9, 2009, at 10:09 AM, Zachary Zolton wrote:
Hmm... I can see what Damien is say though, it would be nice to show a
proper release, given the significant changes.
Is there any way we could do a 0.9 release, and then release 0.9.1
with security/replication merged in?
The change is too
The security stuff that's in trunk now doesn't break things, so it
doesn't have to be removed. But it doesn't work with replication at
all yet, so its not useful IMO.
-Damien
On Feb 9, 2009, at 10:32 AM, Jan Lehnardt wrote:
On 9 Feb 2009, at 15:29, Damien Katz wrote:
... the security
On Feb 9, 2009, at 4:06 PM, Chris Anderson wrote:
* Incremental Map Reduce
- This is also strong right now. It could be faster, but so far it's
been fast enough.
I'd like to see built-in reductions for simple and commonly used
things like count, sum, average, etc. When used it would
On Feb 9, 2009, at 5:59 PM, Antony Blakey wrote:
OK, I give up.
Given compaction and/or revision pruning (as Damien has proposed in
another thread), even generic 'Eventual Consistency' isn't guaranteed.
Revision stemming is 100% optional, and the compaction works the same
as it did
On Feb 10, 2009, at 10:19 AM, Jan Lehnardt wrote:
Hi,
Alex and I are working on our stats package patch and the last
bigger issue is the API. It is just exposing a bunch of values by
keys, but as usual, the devil is in the details.
Let me explain.
There are two types of counters. Hit
, at 2:17 AM, Damien Katz wrote:
[snip]
Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There is nothing more difficult to plan, more doubtful of success,
nor more dangerous to manage than the creation of a new order of
things... Whenever his enemies have the ability
On Feb 11, 2009, at 7:06 PM, Damien Katz wrote:
On Feb 11, 2009, at 5:36 PM, Antony Blakey wrote:
On 12/02/2009, at 8:13 AM, Damien Katz wrote:
Hi Antony. Just to clarify, there is no vote, as there is no patch
ready yet.
Sorry Damien, jumped the gun.
And I think you don't want
So there have been some grumbling that the test suite could use some
changes.
A small problem I see is the use of couch.js in the tests. I'd
personally like to remove the Javascript couch.js library usage from
the tests and instead use more naked HTTP calls and simple sub-routines.
My
So based on the responses, it looks like we need fully automated
tests, runnable without the browser. And Erlang unit test integration.
Also people like running the tests in the browser and want even better
integration for creating new tests. I see no reason we cannot have
both. Chris
This might not cause problems for us, but what about downstream
projects?
-Damien
On Feb 15, 2009, at 8:32 PM, Chris Anderson wrote:
On Sun, Feb 15, 2009 at 5:09 PM, Gianugo Rabellino
gian...@gmail.com wrote:
On Sun, Feb 15, 2009 at 2:15 AM, Jan Lehnardt j...@apache.org wrote:
Hi,
I
comments below
On Feb 17, 2009, at 6:53 AM, Jan Lehnardt wrote:
--
index.html: A portal page. At the moment, the first thing you see in
Futon is
the list of databases. I'd like to see (as an replacement or an
addition needs
to be discussed), a welcome page, a portal if you will, that
For their ongoing contributions to Apache CouchDB and it's community.
I am pleased to announce two new committers, Paul Davis and Adam
Kocoloski.
Thank you both for your excellent work, we all love what you've been
doing. Now we want you to do it even more ;)
-Damien
Not that I necessarily disagree (this might be the most pragmatic
way), but it kind of defeats the whole point of HTTP headers. It's
just taking the same inputs and making them slightly harder to parse.
-Damien
On Feb 18, 2009, at 7:41 PM, Chris Anderson wrote:
On Wed, Feb 18, 2009 at
On Feb 20, 2009, at 1:55 PM, Stefan Karpinski wrote:
Hi, I thought I'd introduce myself since I'm new here on the couchdb
list. I'm Stefan Karpinski. I've worked in the Monitoring Group at
Akamai, Operations RD at Citrix Online, and I'm nearly done with a
PhD in computer networking at the
On Feb 20, 2009, at 4:37 PM, Stefan Karpinski wrote:
Trees would be overkill except for with very large clusters.
With CouchDB map views, you need to combine results from every node
in a
big merge sort. If you combine all results at a single node, the
single
clients ability to
Heh, I've done that too.
-Damien
On Feb 22, 2009, at 10:31 AM, Jan Lehnardt wrote:
Cheers Ben,
indeed, the files didn't make it into the commit.
They are now in as of r746734.
Thanks again.
Jan
--
On 22 Feb 2009, at 15:34, Ben Browning wrote:
Jan,
Trying to compile the latest trunk I
?
old_rev_that_might_still_be_on_disk=
- Don't call them revisions, call them turd blossoms or hobo
socks. People won't know what they are, but at least they won't
misuse them.
-Damien
Begin forwarded message:
From: Damien Katz dam...@apache.org
Date: February 23, 2009 9:09:09 AM EST
To: u...@couchdb.apache.org
Subject
On Feb 23, 2009, at 8:45 PM, Chris Anderson wrote:
Would it be overly difficult to just add in the ability to keep a
full rev
history based on a config setting?
This would be a pretty big change. As Antony says, once you go down
that path a little, you end up at something that is not
On Feb 24, 2009, at 6:26 AM, Antony Blakey wrote:
On 24/02/2009, at 9:29 PM, Jan Lehnardt wrote:
CouchDB documents are limited to JSON (application/json) as the
content, that doesn't make the API less RESTful. If that's not the
right answer, I don't understand what you mean.
On Feb 23, 2009, at 9:51 AM, Jan Lehnardt wrote:
On 22 Feb 2009, at 15:06, Jan Lehnardt wrote:
I mentioned this in an earlier mail but I'd like to bring it up
again,
since your input is needed here. Metrics are identified with a
tuple `{Module, Key}`. `Module` is the module that initiates
I'll once again state my objection to the newlines, which is actually
kind of weak.
If we compute the revids deterministically (hash the canonical doc
contents), then when we return the document back to the client, we can
send as an integrity hash the same revid, because it is already pre-
That's Ok Noah. Right now, all I've got are some vague ideas, no code.
I've stated my case, unless someone else has stronger objections (or
actual code) I'm fine to leave it as is.
-Damien
On Feb 24, 2009, at 1:19 PM, Noah Slater wrote:
On Tue, Feb 24, 2009 at 01:13:31PM -0500, Damien
On Feb 24, 2009, at 2:13 PM, Paul Davis wrote:
I'm a fan of the no-metadata-in-documents concept, but there are some
issues both philosophical and practical. Philosophically speaking, as
pointed out by the HTTP headers thread, we may be abusing headers when
we consider some of the more CouchDB
The replication security branch is finally near completion, this work
is makes CouchDB enforces security during replication, to allow
CouchDB databases to be exposed directly to clients and replicators.
svn co http://svn.apache.org/repos/asf/couchdb/branches/rep_security
This branch also has
On Mar 4, 2009, at 8:34 PM, Adam Kocoloski wrote:
Hi folks, we've been running into a problem where multiple
replications with the same source and target are running
simultaneously. This introduces quite a lot of unnecessary network
traffic and causes real problems with update collisions
On Mar 4, 2009, at 8:34 PM, Adam Kocoloski wrote:
I was working through some replication tickets this week and
thinking more and more that the replicator could benefit from being
restructured along OTP principles. So, I went ahead and did it.
Here's the structure I've worked out so far:
On Mar 5, 2009, at 5:34 PM, Jan Lehnardt wrote:
On 5 Mar 2009, at 21:38, Christopher Lenz wrote:
I think that, at least for the time being, it's best if CouchApp
remained a separate project, in the sense that nothing in CouchDB
should know about the CouchApp side. I certainly agree that
On Mar 6, 2009, at 9:13 AM, Damien Katz wrote:
On Mar 5, 2009, at 12:44 PM, Adam Kocoloski wrote:
On Mar 4, 2009, at 3:24 PM, Damien Katz wrote:
The replication security branch is finally near completion, this
work is makes CouchDB enforces security during replication, to
allow CouchDB
On Mar 7, 2009, at 7:35 PM, Antony Blakey wrote:
On 08/03/2009, at 10:48 AM, Jan Lehnardt wrote:
http://osdir.com/ml/db.couchdb.devel/2008-07/msg00127.html (lmgtfy
safari sends post twice, seriously, this is tiring).
Sorry, I tried a number of searches (e.g. safari double post bug),
On Mar 8, 2009, at 11:33 AM, Antony Blakey wrote:
On 08/03/2009, at 11:47 PM, Benoit Chesneau wrote:
Launching such service is a good idee, and I would say bravo.
Indeed, a commercial culture around CouchDB is a good thing when
trying to sell this technology.
But I think this is
On Mar 9, 2009, at 2:14 PM, Christopher Lenz wrote:
On 06.03.2009, at 18:50, Chris Anderson wrote:
I've removed the Applications column from Futon. The index of
CouchApps could even be it's own CouchApp, so integration questions
can wait indefinitely.
Thanks.
I'd like to push the
I think the rep_security branch is looking pretty solid. I still have
work to do to merge with Adam's recent replicator changes.
This patch breaks the file format and replication API, so replication
with earlier versions is not possible. And the all or nothing w/
conflict checking
On Mar 10, 2009, at 7:06 PM, Chris Anderson wrote:
On Tue, Mar 10, 2009 at 3:44 PM, Damien Katz dam...@apache.org
wrote:
This patch breaks the file format and replication API, so
replication with
earlier versions is not possible.
The rev format has changed. Does this mean
and no errors returned the client.
Now we just need merge to trunk.
-Damien
On Mar 11, 2009, at 11:31 AM, Damien Katz wrote:
I'm going to look into adding a force conflicts option today.
-Damien
On Mar 10, 2009, at 7:01 PM, Jan Lehnardt wrote:
On 10 Mar 2009, at 23:44, Damien Katz wrote
Heh. Hit send too soon. Anyway, I think you get the idea.
-Damien
On Mar 11, 2009, at 6:46 PM, Damien Katz wrote:
I've added all_or_nothing transactions. It has the behavior that if
a document doesn't pass validation or there is a crash during
update, then no docs are saved. However
On Mar 11, 2009, at 7:07 PM, Chris Anderson wrote:
On Wed, Mar 11, 2009 at 8:34 AM, Damien Katz dam...@apache.org
wrote:
On Mar 10, 2009, at 7:06 PM, Chris Anderson wrote:
On Tue, Mar 10, 2009 at 3:44 PM, Damien Katz dam...@apache.org
wrote:
This patch breaks the file format
Atomic bulk docs is in the patch, it just doesn't do conflict
checking. If any docs are conflicts, they are saved anyway as
conflicts. This means it's really for message queue functionality, not
database consistency, your data is safe and committed but might not be
immediately available or
I agree with Jan.
I just realized, I think the planned COMET interfaces for near-
realtime replication will obsolete update the notification process.
That should give us all the flexibility we want here.
-Damien
On Mar 16, 2009, at 8:58 AM, Jan Lehnardt (JIRA) wrote:
[
Now fixed in trunk. Was there a bug report for this?
-Damien
On Mar 16, 2009, at 1:24 PM, Damien Katz wrote:
Good stack trace. Thanks Matt. I think I see the problem already.
-Damien
On Mar 16, 2009, at 1:00 PM, Matt Goodall wrote:
2009/3/16 Matt Goodall matt.good...@gmail.com:
2009/3
You are correct, it does need to be set to true there. Doh. Since I
never hit the problem, I couldn't be sure I fixed it correctly.
-Damien
On Mar 16, 2009, at 5:39 PM, Adam Kocoloski wrote:
Hi Damien, I'm confused. Don't you need to set done=true in the
handle_call for fin?
Adam
On
the conflict checking transaction model. We might
figure out new solutions, tweaked models, etc that work better, or we
might see the pressing need for the transaction style.
-Damien
On Mar 25, 2009, at 4:52 PM, Tim Parkin wrote:
Damien Katz wrote:
You could help by updating the wiki
I think you are too far behind, I fixed a problem with this not too
long ago. If you update to the most recent trunk you shouldn't have
this problem.
-Damien
On Mar 27, 2009, at 3:52 PM, Shaun Lindsay wrote:
Hey all,
We've been seeing this strange error in the couch logs and we're not
You can already get the proposed behavior by using _bulk_docs POST and
all_or_nothing:true with a single document. We can easily add a flag
to single doc PUTs too.
The interactive conflict behavior in CouchDB is useful for completely
eliminating persisted conflicts in a lot of replicated
Looks like a bug, you should get a conflict error on the first update.
Please create a bug report with a failing JS test case.
-Damien
On Apr 6, 2009, at 1:42 PM, Matt Goodall wrote:
Hi,
I came across an inconsistency with _bulk_docs when creating new
documents, i.e. calling _bulk_docs
User collation settings (case, accent, sensitive, locale, etc) should
be an option for views if anyone wants to take that on.
On Apr 9, 2009, at 12:49 PM, Paul Davis wrote:
Oddly enough, this is expected behavior:
values.push(a);
values.push(A);
values.push(aa);
values.push(b);
On Apr 9, 2009, at 11:17 AM, Paul Davis wrote:
Kenneth,
I'm pretty sure you're issue is in the reduce steps for the daily and
montly views. The general rule of thumb is that you shouldn't be
returning data that grows faster than log(#keys processed) where as I
believe your data is growing
If you don't trap exits, then the default OTP behavior is to propagate
linked exit messages to other child linked process, killing the entire
process tree. The exception is for linked normal exits, which have no
effect on non-trapping gen_server processes. They are just ignored. I
think
Begin forwarded message:
From: Damien Katz dam...@apache.org
Date: April 12, 2009 10:35:33 PM EDT
To: bo...@apache.org
Subject: [REPORT] CouchDB
CouchDB is a document oriented database.
- Community -
CouchHack is a informal CouchDB hacker event being held in Asheville
April
19-22. We
I have no plans to implement that interface. Looks to be more
complicated than necessary for our needs. Support can be added later
though.
-Damien
On Apr 13, 2009, at 7:44 AM, Vicente Jiménez wrote:
I only have a question about the future Comet interface:
It's is going to be based on the
Fine with me.
-Damien
On Apr 13, 2009, at 2:41 PM, Jan Lehnardt wrote:
Hi,
as I understand trunk is now effectively 0.10-dev. Do we want to
maintain the 0.9.x branch and backport some of the bug fixes that
go into trunk? (I'd say yes we do.)
If yes, I'd like to propose the following commits
On Apr 14, 2009, at 2:09 PM, Chris Anderson wrote:
On Tue, Apr 14, 2009 at 10:16 AM, Noah Slater nsla...@apache.org
wrote:
On Tue, Apr 14, 2009 at 06:13:03PM +0100, Simon Lucy wrote:
This implies that all development on trunk is targetted at that
release,
is that actually true? Different
Just a reminder, ApacheCon US 2009 wants very much to see more CouchDB
topics and participation as there is a lot of interest in both CouchDB
and Erlang. Though the deadlines have passed, I have a feeling talks
involving one or both will still have a higher than normal chance of
being
On May 5, 2009, at 9:12 AM, Adam Kocoloski wrote:
On May 4, 2009, at 9:32 PM, Chris Anderson wrote:
Devs,
Are we ready for 0.9.1? My pet patch is in and backported, how
about yours?
I wonder if we should try to shore up the JIRA records of what's in
0.9.1. Currently I see
+1 for committing.
-Damien
On May 10, 2009, at 9:49 PM, Paul Davis wrote:
Chris reminded me that I had an optimization patch laying around for
couch_btree:chunkify and his tests show that it gets a bit of a speed
increase when running some tests with hovercraft. The basic outline of
what I
On May 11, 2009, at 4:56 PM, Brian Candler wrote:
I notice that:
* DELETE lets you specify ...?rev= as part of the URL
I did it this way so don't have have to put the _rev in a json body of
the DELETE request.
* But PUT doesn't (it seems to ignore it)
PUT and POST, you put the
On May 12, 2009, at 5:55 AM, Brian Candler wrote:
On Mon, May 11, 2009 at 05:12:51PM -0400, Damien Katz wrote:
* DELETE lets you specify ...?rev= as part of the URL
I did it this way so don't have have to put the _rev in a json body
of
the DELETE request.
* But PUT doesn't
On May 13, 2009, at 9:39 PM, Jan Lehnardt wrote:
On 14 May 2009, at 03:17, Damien Katz wrote:
We have to both block and merge commits? It seems like we should
only need to do one or the other, but not both.
We need block or merge a commit for any stable branch
(currently 0.9.x
+%% on rare occasions ibrowse seems to process a chunked response
incorrectly
+%% and include an extra \r in the last chunk. This code ensures
that we
+%% truncate the downloaed attachment at the length specified in the
metadata.
That really sucks. We need to either fix ibrowse or drop it
, such as a couchdb file attached inside a document
in a live db, or an intentional attack.
-Damien
On May 18, 2009, at 7:43 PM, Chris Anderson wrote:
On Mon, May 18, 2009 at 10:59 AM, Damien Katz dam...@apache.org
wrote:
Feedback on all this welcome. Please try out the branch to shake
out any
bugs
On May 18, 2009, at 7:43 PM, Chris Anderson wrote:
On Mon, May 18, 2009 at 10:59 AM, Damien Katz dam...@apache.org
wrote:
Feedback on all this welcome. Please try out the branch to shake
out any
bugs or performance problems that might be lurking.
The code looks simpler, which is a nice
On May 20, 2009, at 11:26 AM, Paul Davis wrote:
On Wed, May 20, 2009 at 11:22 AM, Damien Katz dam...@apache.org
wrote:
On May 20, 2009, at 11:09 AM, Damien Katz wrote:
Previously, only btree nodes were saved compressed and docs were
not. I
didn't realize the compression was so expensive
On May 20, 2009, at 11:09 AM, Damien Katz wrote:
Previously, only btree nodes were saved compressed and docs were
not. I didn't realize the compression was so expensive, but now that
I switch it off on both the branch and on trunk, I see big
performance boosts for both. And now the tail
On May 20, 2009, at 4:12 AM, Brian Candler wrote:
On Mon, May 18, 2009 at 01:59:08PM -0400, Damien Katz wrote:
If you have an application where you don't mind
losing your most recent updates, you could turn off fsync all
together.
However, this assumes ordered-sequential writes, that the FS
I'm not sure this is fixable with the current architecture. The
problem are the rules used to determine the current winner are:
Is Not Deleted has the most edits highest revid
To force one document to be a winning conflict on another document
would require the second rule to be changed or
On May 18, 2009, at 1:59 PM, Damien Katz wrote:
In branches/tail_header on the svn repository is an working version
of new pure tail append code for CouchDB.
Right now in trunk we have zero-overwrite storage, which meant we
never overwrite any previously committed data, or meta data
Thanks, forwarding to the dev list.
On May 25, 2009, at 11:19 AM, Ziyad Saeed wrote:
Hello Damien
If I package Couchdb in my Adobe air application, can I use the
buildin Squirrelfish javascript engine (webkit) for couchdb, or do I
have to package Spidermonkey with my app.
Thankyou
Oops, I fowarded the wrong thing! Sorry.
-Damien
On May 25, 2009, at 12:46 PM, Damien Katz wrote:
Thanks, forwarding to the dev list.
On May 25, 2009, at 11:19 AM, Ziyad Saeed wrote:
Hello Damien
If I package Couchdb in my Adobe air application, can I use the
buildin Squirrelfish
Anyway, To answer the question, I don't know. Maybe someone on the dev
list knows.
-Damien
On May 25, 2009, at 12:46 PM, Damien Katz wrote:
Thanks, forwarding to the dev list.
On May 25, 2009, at 11:19 AM, Ziyad Saeed wrote:
Hello Damien
If I package Couchdb in my Adobe air application
This is what I meant to forward to the dev list. Anyway want to add
this?
-Damien
Begin forwarded message:
From: GitHub nore...@github.com
Date: May 25, 2009 8:44:18 AM EDT
To: damien_k...@yahoo.com
Subject: [GitHub] lachlanhardy sent you a message
lachlanhardy wants you to pull from
On May 27, 2009, at 4:05 PM, Brian Candler wrote:
On Wed, May 27, 2009 at 07:41:54PM +0200, Jan Lehnardt wrote:
`GET /db/doc?conflicts=true` gives you a new `_conflicts` member
with an
array value of all conflicting revisions (that you then have to fetch
separately).
I know that - but not
On May 28, 2009, at 10:19 AM, Brian Candler wrote:
You can use [open_]revs=all to open all the conflicts (deleted
conflicts
too)
Ah, open_revs=all is new to me - it works fine, although knowing about
deleted revisions isn't of particular interest. What I want is all
live
(current)
1 - 100 of 293 matches
Mail list logo
