On 6 Jan 2009, at 02:36, Chris Anderson wrote:
On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz
wrote:
So, um, can we get this change backed out?
+1 on deleting the feature altogether. It's parallel code in places
and doesn't provide any functionality.
+1
--
Jason Davies
www.jasondav
On Mon, Jan 5, 2009 at 23:07, Chris Anderson wrote:
> Again, I'm not sure that having the rev available on the view row
> makes a difference. The indexer cares about the keys and values, if
> they've changed, they've changed.
>
This is true. However, it could be very expensive to compare the key
On 06/01/2009, at 2:37 PM, Chris Anderson wrote:
The first gotcha I can see for the db uuid, is that for a cluster,
which we want to be a single logical db, even if there are many nodes
involved, would it be better to have a uuid per physical couch
instance, or a single uuid for the cluster?
On Mon, Jan 5, 2009 at 7:30 PM, Antony Blakey wrote:
>
> On 06/01/2009, at 1:33 PM, Chris Anderson wrote:
>
>> You could put it in doc._db_uuid.
>
> OTOH, I guess you could make it such that it is ignored by the db when
> writing, and inserted when returning the document. And maybe as a "where did
On 06/01/2009, at 1:33 PM, Chris Anderson wrote:
You could put it in doc._db_uuid.
But it's not a document property - it qualifies the id/rev within a
value space, but it shouldn't travel with the document because it's a
function of which replica you happened to retrieve it from.
OTOH,
On Mon, Jan 5, 2009 at 7:03 PM, Chris Anderson wrote:
>
> CouchDB can't tell, without regenerating the view index, whether a
> given document update will effect a given key range of the view.
Sorry, to be clear I mean "without updating the view index" - updates
are much less expensive than a full
On Mon, Jan 5, 2009 at 6:52 PM, Antony Blakey wrote:
>> 1. Provide the document rev whenever the id is returned, such as view
>
>> results i.e. not in the document, but in the per-row hash.
>
>
> I meant in the per-row hash *as well*. I'm not suggesting changing anything
> in the document, althoug
1. Provide the document rev whenever the id is returned, such as view
results i.e. not in the document, but in the per-row hash.
I meant in the per-row hash *as well*. I'm not suggesting changing
anything in the document, although the raw document get should return
the db UUID, and I gue
On 06/01/2009, at 1:06 PM, Chris Anderson wrote:
On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz
wrote:
So, um, can we get this change backed out?
+1 on deleting the feature altogether. It's parallel code in places
and doesn't provide any functionality.
+1
Antony Blakey
-
On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz wrote:
>
> So, um, can we get this change backed out?
>
+1 on deleting the feature altogether. It's parallel code in places
and doesn't provide any functionality.
Backing out the change doesn't bother me. I don't feel strongly about
what it's call
On 06/01/2009, at 4:57 AM, Robert Dionne wrote:
First, I'm a little confused by the use of the phrase referential
transparency as I understand the more technical definition in the FP
literature (call a function twice on the same input and get the same
output), but I think I see the intende
On 05.01.2009, at 12:31, Antony Blakey wrote:
How about relying on documentation?
This view may be slow (or not, for a small db). I might use it for
testing or ad-hoc maintenance. Who knows? The one thing you can say
for certain is that it is temporary, unlike every other view. That
is the
On 5 Jan 2009, at 18:54, Damien Katz wrote:
The last remaining work item is db server crash detection, so that
clients can detect when a server has crashed and potentially lost
updates. This is pretty simple, each db server just needs a unique
ID generated at it's startup. Client retrieve t
On Jan 5, 2009, at 1:59 PM, Geir Magnusson Jr. wrote:
On Jan 5, 2009, at 12:54 PM, Damien Katz wrote:
It was brought to my attention that commits on OS X were very slow
with the latest releases of Erlang. After I upgraded to the most
recent version, I found them to be indeed slow, slowing
I guess I can answer my own question, Chris' app in the database[1]
idea is a scenario where a user might clone the app then tweak the
design docs.
[1] http://jchris.mfdz.com/code/2008/11/my_couch_or_yours__shareable_ap
On Jan 5, 2009, at 1:27 PM, Robert Dionne wrote:
Interesting proposal
On Jan 5, 2009, at 12:54 PM, Damien Katz wrote:
It was brought to my attention that commits on OS X were very slow
with the latest releases of Erlang. After I upgraded to the most
recent version, I found them to be indeed slow, slowing the tests
down to point it was painful to run them. It
Interesting proposal. A question:
First, I'm a little confused by the use of the phrase referential
transparency as I understand the more technical definition in the FP
literature (call a function twice on the same input and get the same
output), but I think I see the intended meaning, plea
It was brought to my attention that commits on OS X were very slow
with the latest releases of Erlang. After I upgraded to the most
recent version, I found them to be indeed slow, slowing the tests down
to point it was painful to run them. It appears, any disk sync from
Erlang now takes som
I am in agreement with Antony Blakey's statements below. I was
preparing such a statement when I read the post.
I have worked with multiple software packages (as, certainly,
most of you have) which have a form of "debug=true" and the
accompanying *documentation* counseling against using it
On 05/01/2009, at 10:13 PM, Robert Dionne wrote:
In the early days of DB2, queries that were know to be slow were
called ad-hoc and strictly verboten in production code. I can see
where people my want to keep these, even knowing they are slow.
Perhaps _ad_hoc_view would bring provide this
I've cc'd this to couchdb-user, because I think this discussion
belongs on -dev, but everyone watches -user.
One of the great features of Couch is the use of optimistic locking
i.e. rev as a bedrock mechanism, and the way this is permeated through
the API. The combination of id + rev is a r
On Sun, Jan 04, 2009 at 10:10:21PM +0100, Christopher Lenz wrote:
> In general, I think that API changes, even at this point, should be done
> with care. Building a thriving ecosystem of client applications and
> libraries is going to get pretty tough when people get the perception
> that things ch
I can only confirm this:
I ran ab against some static and some dynamic websites [only apache]
and where the speed results were quite different, at first i freaked
out because ab was reporting 99% error rate.
upon further investigation, but with no official confirmation to date,
this is what i dedu
I haven't looked at it yet, been meaning to as mnesia has been
extended[1] to overcome file size limitations and can now use berkely
db or tokyo cabinet.
I think the main difference is that couchdb is a document store and
tokyo cabinet is more of a persistent hash table.
[1] http://www.wa
In the early days of DB2, queries that were know to be slow were
called ad-hoc and strictly verboten in production code. I can see
where people my want to keep these, even knowing they are slow.
Perhaps _ad_hoc_view would bring provide this caution, without
calling them "slow". As was ment
How about relying on documentation?
This view may be slow (or not, for a small db). I might use it for
testing or ad-hoc maintenance. Who knows? The one thing you can say
for certain is that it is temporary, unlike every other view. That is
the defining characteristic of this facility, and
How about _test_view? Kinda gets the point across that it's for
testing.
geir
On Jan 5, 2009, at 5:04 AM, Paul Davis wrote:
On Sun, Jan 4, 2009 at 11:10 AM, Christopher Lenz
wrote:
On 04.01.2009, at 19:38, Jan Lehnardt wrote:
switched.
we happily break the API pre 0.9 :)
I'd like to
On Mon, Jan 5, 2009 at 12:14 AM, Chris Anderson wrote:
> On Sun, Jan 4, 2009 at 2:45 PM, Geir Magnusson Jr. wrote:
>>
>> How many inserts a second can you do on your machine?
>
>
> This the command I'm using to insert into the db:
>
> ab -c 10 -n 1000 -p emptypost -T 'application/json'
> http://1
On Mon, Jan 5, 2009 at 11:04 AM, Paul Davis wrote:
> On Sun, Jan 4, 2009 at 11:10 AM, Christopher Lenz wrote:
>> On 04.01.2009, at 19:38, Jan Lehnardt wrote:
>>>
>>> switched.
>>>
>>> we happily break the API pre 0.9 :)
>>
>> I'd like to throw in a bit of caution here. I agree that API breakage i
On Sun, Jan 4, 2009 at 11:10 AM, Christopher Lenz wrote:
> On 04.01.2009, at 19:38, Jan Lehnardt wrote:
>>
>> switched.
>>
>> we happily break the API pre 0.9 :)
>
> I'd like to throw in a bit of caution here. I agree that API breakage is
> totally acceptable prior to 1.0, but it shouldn't be done
Well, when I asked about the necessity for the then-current level of
commit-to-disk behavior, I got answers like :
On Jan 4, 2009, at 12:45 PM, Jan Lehnardt wrote:
On 4 Jan 2009, at 14:09, Geir Magnusson Jr. wrote:
2) Is anyone using CouchDB in a manner that really requires this
level of
Hi,
I found couchDB is really interesting to explore.
I have a window environment to work with.
I found the windows installer for CouchDB in the following link.
http://wiki.apache.org/couchdb/Installing_on_Windows
I just want to test it for which I need the C/C++ client library.
Can any one p
Geir Magnusson Jr. schrieb:
Doesn't something like this at least warrant a "head up" kind of mail to
the dev list? How does it work? How can I control the asynchronicity?
I just understood that as simply responding to the client before you
really have written everything to disk and queue
I'm confused.
We're in the middle of a discussion on the user list about
performance, I'm told in no uncertain terms that this extreme level of
commit is absolutely required to avoid db corruption because no one
can control what the Erlang VM does (or something...) and without a
word of
Geir Magnusson Jr. wrote:
I do think, that going forward, it would be very cool to have a
performance benchmark suite, that was integrated perhaps with Hudson
or some other Apache tools. Being able to see our changes effect on
performance as we go along will certainly push us in the right
direct
Geir Magnusson Jr. wrote:
Well, what he reported for the simple insert test is startling, isn't it?
From 200/sec -> 8/sec between the two versions?
It will be interesting to see if there's a similar slowdown on linux.
I'm guessing he's on OS X since it's hit the magic number of 8 ("...
not
On 5 Jan 2009, at 08:51, Alan Bell wrote:
I just upgraded to the SVN code and it got nearly 5 times faster on
inserting empty documents I am now up to 390/second on the same
hardware that got 80/second before. This machine does recreate_doc
in 365ms in the test suite.
I'm assuming the spe
On Jan 5, 2009, at 1:19 AM, Chris Anderson wrote:
On Sun, Jan 4, 2009 at 9:20 PM, Lawrence Pit
wrote:
So for example the test recreate_doc, which hasn't changed for
months, takes
345ms using v0.8 and 4406ms using v0.9. That's more than 10 times
slower.
Same machine, same erlang host.
rsion.
There are more tests than in the past, so that should be a factor.
I'm not talking about the total time, I'm referring to the times of
individual tests. Here's my test run using v0.8:
http://img.skitch.com/20090105-bmutqgq4ag9ba75ynhq6xa69nw.png
and here are the results wh
On Jan 5, 2009, at 3:17 AM, Sven Helmberger wrote:
Damien Katz schrieb:
Everyone who has tried my experiment on IRC has reported the same
numbers. I can get 6/sec on a laptop (2.5GHz core2 dual core MBP
w/ 4GB ram and a 7200rpm disk), and 8/sec on my desktop (a quad-
core, 8 GB w/ raided
Damien Katz schrieb:
Everyone who has tried my experiment on IRC has reported the same
numbers. I can get 6/sec on a laptop (2.5GHz core2 dual core MBP w/
4GB ram and a 7200rpm disk), and 8/sec on my desktop (a quad-core, 8
GB w/ raided 7200rpm disks, IIRC)
geir
Okay, very well. If you fi
41 matches
Mail list logo
